|
From: Nicholas N. <nj...@ca...> - 2004-01-25 18:35:08
Attachments:
diff
|
On Tue, 20 Jan 2004, Tom Hughes wrote: > Mukund has confirmed to me that it is only normal kernel locking that > he is talking about, so I think it is only epoll_wait that we need to > consider as blocking. Attached is a my attempt to add epoll support to the CVS HEAD. I'm not sure about the use of the "#ifdef KERNEL_2_6" in vg_syscalls.c, however. It was my attempt to cope with "struct epoll_event" not being available in 2.4 and earlier kernels. Also, I'm not super confident about the checking of the arguments; my patch is based on the patch at www.fefe.de/diffs/, but I changed the argument checking a little bit, because I don't think it was correct. Finally, I haven't actually tried it because my machine is still running a 2.4 kernel... N |
|
From: Jeremy F. <je...@go...> - 2004-01-25 20:52:49
|
On Sun, 2004-01-25 at 10:35, Nicholas Nethercote wrote: > Attached is a my attempt to add epoll support to the CVS HEAD. I'm not > sure about the use of the "#ifdef KERNEL_2_6" in vg_syscalls.c, however. > It was my attempt to cope with "struct epoll_event" not being available in > 2.4 and earlier kernels. I would be inclined to copy the definition into vg_kerneliface.h, and make it all unconditional. If the underlying kernel doesn't support the syscall, then it will fail properly. As much as possible, I'd like to eliminate compile-time dependencies on particular kernel versions. J |
|
From: Nicholas N. <nj...@ca...> - 2004-01-26 22:02:47
Attachments:
epoll.patch
|
On Sun, 25 Jan 2004, Jeremy Fitzhardinge wrote: > > Attached is a my attempt to add epoll support to the CVS HEAD. I'm not > > sure about the use of the "#ifdef KERNEL_2_6" in vg_syscalls.c, however. > > It was my attempt to cope with "struct epoll_event" not being available in > > 2.4 and earlier kernels. > > I would be inclined to copy the definition into vg_kerneliface.h, and > make it all unconditional. If the underlying kernel doesn't support the > syscall, then it will fail properly. As much as possible, I'd like to > eliminate compile-time dependencies on particular kernel versions. Done, new patch attached. Anyone think it ok to commit? N |
|
From: Tom H. <th...@cy...> - 2004-01-26 22:15:24
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sun, 25 Jan 2004, Jeremy Fitzhardinge wrote:
>
> > I would be inclined to copy the definition into vg_kerneliface.h, and
> > make it all unconditional. If the underlying kernel doesn't support the
> > syscall, then it will fail properly. As much as possible, I'd like to
> > eliminate compile-time dependencies on particular kernel versions.
>
> Done, new patch attached. Anyone think it ok to commit?
Should the FD returned by epoll_create() be recorded for the FD tracking
code?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Robert W. <rj...@du...> - 2004-01-26 22:18:59
|
> Should the FD returned by epoll_create() be recorded for the FD tracking > code? If it creates an FD visible to user code, then yes. |
|
From: Nicholas N. <nj...@ca...> - 2004-01-31 23:09:11
Attachments:
epoll.patch
|
On Mon, 26 Jan 2004, Robert Walsh wrote: > > Should the FD returned by epoll_create() be recorded for the FD tracking > > code? > > If it creates an FD visible to user code, then yes. Ok, third time lucky... One thing I wasn't sure about: do I need to include a call to fd_allowed()? Not every call to record_fd_opened() is preceded by one (eg. fcntl()), although most are... maybe the missing ones are oversights? N |
|
From: Robert W. <rj...@du...> - 2004-02-01 06:29:39
|
> One thing I wasn't sure about: do I need to include a call to > fd_allowed()? Not every call to record_fd_opened() is preceded by one > (eg. fcntl()), although most are... maybe the missing ones are oversights= ? I don't know - that was something Jeremy put in, to check if the file descriptor is within the range allowed for use by the client. I think.=20 Jeremy? Help! Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |