emantics seems to be
more useful. So I guess, no change is the way to go here.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD
duce the amount of code quite a bit.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHO47s2ijCOnn/RHQRApIIAJwNATDabXkfszG2e+gtJWO9f4wm4wCdFuoQ
Yn40KK+cs9Di4fq+WKTQalo=
=q02M
-END PGP SIGNATURE--
type
It would be so much nicer if the device type would be part of the
RTM_GETADDR data, or at least the RTM_GETLINK data.
Any help on any of these issues?
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/
ngineering for proposals for
changes to the POSIX spec and Alan replied.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG9Uyl2ijCOnn/RHQRAtyNAJ0TLrZ8P3VcoFDWT1g+Qft1eTU+1QCffus6
Tljy9S9Sxb7z09l/
ady handles this port.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG9UDy2ijCOnn/RHQRAvntAKC6F6Pz6zHd/iZLFECOZ0MxlhdPBQCgjrLC
V9cazPF5jjf2eUSr7ZKDSas=
=0v1W
-END PGP SIGNATURE-
-
To unsub
on in the next few
months so that we, in theory, can check whether the text in the
specification makes sense.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG813Z2ijCOnn/RHQRAsNkAJ9EuDWX3ED
ut for IPv4/6 it's not an issue. Some implementations might
handle all-zeros and the spec _currently_ calls for it. In this case an
alignment would be good.
I guess I'll just go ahead and file a problem report with the spec.
Maybe the Unix vendors will test their implementations in
)
> on UDP/RAW and it's certainly possible to connect() to that.
Where do you get this from? And where is this implemented? I don't
doubt it but I have to convince people to change the standard and
possibly introduce incompatibility.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 4
F_UNSPEC
But the spec calls for null address for the protocol.
That means the family for the null address is the same as the family of
the socket.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG8WCO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ulrich Drepper wrote:
> Yes, but for IPv4/6 it's not an issue. Some implementations might
> handle all-zeros and the spec _currently_ calls for it. In this case an
> alignment would be good.
Searching the web shows
socket, connect to one address, call connect with a "null
address", then connect to another address (which likely has to use a
different interface since otherwise the connect will just succeed, it
seems).
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN
can point to other
implementations doing the same as Linux) let me know and I'll work on
getting the spec changed.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG8T6L2ijCOnn/RHQRAnSRAJ9sXDGG9OepEQWQIna
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I guess the request is not that useful. The family of the socket is
determined earlier so to undo this it takes more of an effort. I
managed to get by for most cases without this change so no action needed.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc
itself is reset.
Is this functionality which got lost over time? Or is the man page
wrong and this never was the case? Is this a worthwhile change?
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/L
Take two: I forgot to change the compat code. This has now happened. Only one
additional line changed.
Everything else from the first patch remains the same. I try to avoid clogging
the list unnecessarily by not resending the test program.
Signed-off-by: Ulrich Drepper <[EMAIL PROTEC
Take two: I forgot to change the compat code. This has now happened. Only one
additional line changed.
Everything else from the first patch remains the same. I try to avoid clogging
the list unnecessarily by not resending the test program.
Signed-off-by: Ulrich Drepper <[EMAIL PROTEC
);
int fd = *(int *) CMSG_DATA (cmsg);
if (fd == -1)
error (1, 0, "no descriptor received");
char fdname[20];
snprintf (fdname, sizeof (fdname), "%d", fd);
execl ("/proc/self/exe", argv[0], fdname, NULL);
puts ("execl failed");
return 1;
}
David Miller wrote:
> Something more scalable has to be used.
This is where the shared-memory based event notification comes in. It
was always also meant to be used for things like this.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Descript
must be memory based. Something like "register a word
which is set when an event arrives" is a much better interface. Who you
then go and retrieve messages is another issue. If this is a rare event
then opening is new netlink socket is no problem.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 44
Evgeniy Polyakov wrote:
> I think that mean that everybody is happy with APi, design and set of
> features.
No comment means that I still have not been able to test anything since
regardless of what version I tried, it failed to build.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Cas
vel code
generating a signal with kill().
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
Evgeniy Polyakov wrote:
It _IS_ how previous interface worked.
EXACTLY!
No, the old interface committed everything not only up to a given index.
This is the huge difference which makes or breaks it.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To
but as you have probably noticed,
there was such an interface already, and I changed it. So, this will be the
last change of the interface. You think it should not be exported -
fine, it will not be.
Thanks.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubs
a flag
is much more complicated than adding a simple index comparison before
going to sleep.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED
ts are in any way sufficient. The interface is
already too big and this is 100% duplicate functionality. If there are
performance problems with the POSIX timer implementation (and I have yet
to see indications) it should be fixed instead of worked around.
--
➧ Ulrich Drepper ➧ Red Hat, Inc.
an be passed to userland in one or two int fields, I don't really
care. When reporting the event to the user code we cannot just point
into the ring buffer anyway. So while copying the data we can rewrite
it if necessary. I see no need to complicate the code more than it
already is.
-
onality we'd need to use indirect notification via
>> signal or pipe or something like that.
This is still something which is wanted.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe netdev" i
ue is sufficient and it should be passed up
to the user in the ptr member of struct ukevent.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordom
ove ring buffer things in userspace with
kevent_get_events() and this functionality is there for almost a year :)
Again, this defeats the purpose completely. The ring buffer is the
faster interface, especially when coupled with asynchronous filling of
ring buffer (i.e., without a syscal).
=
- there is really no reason to invent yet another timer implementation.
We have the POSIX timers which are feature rich and nicely
implemented. All that is needed is to implement SIGEV_KEVENT as a
notification mechanism. The timer is registered as part of the
timer_create() sy
hate it and want to fight it.
Mmap implementation can be added separately, since it does not affect
kevent core.
That I doubt very much and it is why I would not want the kevent stuff
go into any released kernel until that "detail" is resolved.
--
➧ Ulrich Drepper ➧ Red Hat, Inc.
call should have no
timeout parameter at all. Fact is that setting up a timer is not for
free. Since the timeout is used all the time having a timeout parameter
is the right answer. And if you do this then do it right just like
every other syscall other than poll: use a timespec object. This gi
out how to implement it correctly.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
nttmo, ...)
Not only is this much more expensive to do at userlevel, it is also
inadequate because calls to settimeofday() do not cause a recomputation
of the timeout.
See Ingo's RT futex stuff as an example for a kernel interface which
does it right.
--
➧ Ulrich Drepper ➧ Red Hat, I
es etc. See the clock_nanosleep() interface
for a way this can be useful.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
On 10/3/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
http://tservice.net.ru/~s0mbre/archive/kevent/evserver_kevent.c
http://tservice.net.ru/~s0mbre/archive/kevent/evtest.c
These are simple programs which by themselves have problems. For
instance, I consider a very bad idea to hardcode the s
xt, we should/must be able to specify which clock the
timeout is for (not as part of the wait call, but another control
operation perhaps). It's important to distinguish between
CLOCK_REALTIME and CLOCK_MONOTONE. Both have their use.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mount
urrent wait interface. We need this signal mask
interfaces and the appropriate setup code.
Being able to get signal notifications does not mean this is always the
way it can and must happen.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: O
On 9/20/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
This patch includes core kevent files:
[...]
I tried to look at the example programs before and failed. I tried
again. Where can I find up-to-date example code?
Some other points:
- I really would prefer not to rush all this into the u
[Bah, sent too eaqrly]
On 9/22/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
The only two things missed in patchset after his suggestions are
new POSIX-like interface, which I personally consider as very unconvenient,
This means you really do not know at all what this is about. We
already h
On 9/22/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
The only two things missed in patchset after his suggestions are
new POSIX-like interface, which I personally consider as very unconvenient,
This means you really do not know at all what this is about. We
already have these interfaces. S
On 9/27/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
\> I have been told in private what is signal masks about - just to wait
until either signal or given condition is ready, but in that case just
add additional kevent user like AIO complete or netwrok notification
and wait until either reques
On 8/31/06, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
Sorry ofr long delay - I was on small vacations.
No vacation here, but travel nontheless.
> - one point of critique which applied to many proposals over the years:
> multiplexer syscalls a bad, really bad. [...]
Can you convince Chris
interface and to have smooth integration with existing
functionality.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
e whether the ring state changed. If yes, the syscall
returns immediate with -ENWOULDBLOCK. Otherwise it is queued for
waiting.
With these steps and the requirement that all ring buffer entries are
processed FIFO we can
a) avoid syscalls to avoid freeing ring buffer entries
b) detect
en't seen those either. So if possible, point the world
to them again. If you do that now I'll review everything and write up
my recommendations re the interface before Monday.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
Then they need to be handled separately before or after the
kernel AIO code. This would punish unduly all the 99.9% of the programs
which don't use POSIX AIO for network I/O.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
ould support adding all this assuming the
normal file support (as opposed to direct I/O only) is added, too.
But I have one last question: sockets, pipes and the like are already
supported, right? If this is not the case we have a problem with the
currently proposed lio_listio interface.
--
want to make sure.
Overall, this looks much better than the old code. If the answers to my
questions show that the behavior is compatible with the POSIX AIO code
I'm certainly very much in favor of adding the kernel code.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
Especially on 64-bit machines address space really is no limitation
anymore. So, allocate as much as needed, allocate memory when it's
needed, and don't resize.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
we likely need a mechanism to mmap the ring buffer only
based on the file descriptor. I'm not sure about this, though.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
been shown to be a
problem and that a ring buffer implementation with something other than
simple front and back pointers is preferable.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
details. The way those ports are specified doesn't allow much room for
further optimizations. E.g., the userlevel ring buffer isn't possible.
But mostly it's the same semantics. The ec_t type in my text is also
better a file descriptor since otherwise it cannot be transported via
Un
p the CPUs
busy without resorting to a gazillion separate threads in each program.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
oblems with users of
the earlier interface.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
stio
would be nice which also takes another parameter specifying how many of
the NENT aiocbs have to finish before the call returns.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
has the patch done. But I don't know her
schedule.
Important here is, don't base any decision on the current aio
implementation.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
signature.asc
Description: OpenPGP digital signature
57 matches
Mail list logo
