|
|
 Up |
|
|
  |
Author: zhengdazhengda
Date: Jun 30, 2008 07:44
>> Last time on IRC, if I understand it correctly, you said the
>> optimization is to make all packets go through the kernel, and the
>> kernel dispatches the packet with the BPF.
>>
>
> Not quite. The idea was that if you have a multiplexer sitting directly
> on the kernel interface, it could just upload the rules to the kernel,
> instead of running the BPF implementation itself. But that is only a
> minor additional optimization in a specific situation.
>
> The main idea was that if we have filter translators sitting on a
> multiplexer, the filter rules could be combined with the user-supplied
> rules and all be handled in the multiplexer's BPF implementation, rather
> than actually filtering them twice..
I think it's quite similar as I said before. Maybe I used some words
that made you confused.
I said the multiplexer (or the hypervisor, I'm not very sensitive to the
name:-) can have multiple interfaces and there was a "filter" behind
every interface. ...
|
| Show full article (1.46Kb) |
|
| |
no comments
|
|
|
Author: zhengdazhengda
Date: Jun 30, 2008 06:14
>> Do you mean the indentation here? It is caused by '-' and '+' in the
>> beginning of lines.
>>
>
> Ah, I see it now. That shouldn't happen, though. How did you generate
> the patch?
>
for this case, I use
diff -u glibc-2.7-old/hurd/hurdsock.c glibc-2.7/hurd/hurdsock.c
Zheng Da
|
| |
|
| |
no comments
|
|
|
Author: zhengdazhengda
Date: Jun 30, 2008 06:10
> The only difference between translators and other programs is that a
> translator uses the bootstrap port, while other programs ignore it. As
> the translator subprocess is forked from the "outer" helper program
> invoked through settrans, the bootstrap port is copied to it. The helper
> program ignores it, the translator uses it. No problem here.
>
> It is possible to create the weirdest settrans commands; you can
> actually put complete shell scripts there... Ask Thomas Schwinge for
> some crazy examples ;-) (See
> http://lists.gnu.org/archive/html/bug-hurd/2007-04/msg00008.html )
> Indeed, the command is so weird:)
> Sorry, I was unclear: I did actually understand all that. I just meant
> that I was at a loss as to how to handle it...
>
> In the meantime, it dawned upon me however. I don't know how these
> things work exactly, so I'm not sure this is correct... AIUI every
> process has it's own port for proc, right?
> ...
|
| Show full article (2.08Kb) |
|
no comments
|
|
|
Author: zhengdazhengda
Date: Jun 30, 2008 05:39
Kalle Olavi Niemitalo wrote:
> zhengda gmail.com> writes:
>
> >> Anyway, I provide two more environment variables SOCK_INET_SERV_PATH
>> and SOCK_LOCAL_SERV_PATH for the pfinet server and pflocal server,
>> respectively.
>> I try to make my code meet the GNU coding standard.
>>
>
> http://www.gnu.org/prep/standards/standards.html#GNU-Manuals
>
> # Please do not use the term “pathname” that is used in Unix
> # documentation; use “file name” (two words) instead. We use the
> # term “path” only for search paths, which are lists of directory
> # names.
>
> I wonder if that applies to names of environment variables too.
> Certainly I'd expect SOCK_INET_SERV_PATH to allow a
> colon-delimited list, just like PATH and LD_LIBRARY_PATH. ...
|
| Show full article (0.94Kb) |
|
no comments
|
|
|
Author: Arne BabenhauserheideArne Babenhauserheide
Date: Jun 30, 2008 00:24
Am Sonntag 29 Juni 2008 06:21:16 schrieb olafBuddenhagen@ gmx.net: > I'll try to keep it in mind... But no promises :-)
Thanks anyway :-)
> Sanitizing history is about purging stuff that doesn't matter for the
> end result; not about dropping important information. If people don't
> understand the importance of proper commit messages, you are screwed, no
> matter what workflow.
How do you know now what will be important later on?
>> You just let your system search through a batch changesets at once,
>> then it looks the same for the reviewers as modified history,
Just let your system look at the combined diff of all changesets the user
added during the time he did a specific project, then you effectively have a
cleaned version.
|
| Show full article (8.33Kb) |
|
no comments
|
|
|
|
|
|
|
|
|
|
|
|
Author: olafBuddenhagenolafBuddenhagen
Date: Jun 28, 2008 21:21
Hi,
On Sat, Jun 28, 2008 at 12:25:36PM +0200, Arne Babenhauserheide wrote:
> Am Samstag 28 Juni 2008 04:24:50 schrieb olafBuddenhagen@ gmx.net: >> Well, as you seem to have used Mercurial much more and longer, that
>> isn't really surprising :-) If I learned Mercurial now, I'd most
>> likely hold exactly the opposite opinion... That doesn't really tell
>> much.
>
> Please tell me how it works for you, once you have to use it.
I'll try to keep it in mind... But no promises :-)
>> Actually, this is much easier with a sanitized history. It's always
>> clear when and why a change was introduced --
>
> It is only clear that it happened during "implementing feature x", but
> not that it happened during "hacking that damn network table - quick
> fix to get it working".
|
| Show full article (11.57Kb) |
|
no comments
|
|
|
|
|
|
Author: Kalle Olavi NiemitaloKalle Olavi Niemitalo
Date: Jun 28, 2008 07:12
zhengda gmail.com> writes:
> Anyway, I provide two more environment variables SOCK_INET_SERV_PATH
> and SOCK_LOCAL_SERV_PATH for the pfinet server and pflocal server,
> respectively.
> I try to make my code meet the GNU coding standard.
http://www.gnu.org/prep/standards/standards.html#GNU-Manuals
# Please do not use the term “pathname” that is used in Unix
# documentation; use “file name” (two words) instead. We use the
# term “path” only for search paths, which are lists of directory
# names.
I wonder if that applies to names of environment variables too.
Certainly I'd expect SOCK_INET_SERV_PATH to allow a
colon-delimited list, just like PATH and LD_LIBRARY_PATH.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIZkbQHm9IGt60eMgRAtgIAKDokYgzMgfPAZ+UE0caLaDyUh8mJwCfb8Bl
JVpV0kdTv2YKWIe4i1ckIS0=
=jHn1
-----END PGP SIGNATURE-----
|
| |
|
no comments
|
|
|
|
|
|
|
