In article <DIu8oE.G6J@endicor.com> tsarna@endicor.com (Ty Sarna) writes:
>In article <199511292207.RAA11392@glacier.MIT.EDU>,
>Greg Hudson  <ghudson@MIT.EDU> wrote:
>> If we're going to abandon the current select() interface, the right
>> answer is to the use the SVR4 poll(), one of the few things System V
>> did much better than BSD.  (There's the minor weakness that it uses a
>> millisecond timeout, but that's much less of a flaw than those of the
>> select() interface.)
>
>So, why not introduce a "upoll()", and make poll() a simple libc
>wrapper? Or even put it in the kernel, since emulations will probably
>want it anyway.
>
>I agree poll() is cleaner from an API standpoint. However, I fear that
>the changes to implement it in the kernel might be significant and
>far-reaching.
>
>If it does look doable, before tackiling the kernel you could do this as
>a proof-of-concept: start by implementing upoll() as a user-space
>wrapper on select(), and the poll() on top of it.  This will be useful
>in porting NetBSD code to other OSes which have select() but not
>poll(), if NetBSD is converted.  Then implement select() as a wrapper on
>upoll(), which will definately be needed if NetBSD converts.  Then put
>the emulated-select()-on-emulated-upoll()-on-syscall-select() in your
>libc and run your system this way for a while.  That way you can get
>all the bugs ironed out of the userspace, and even get a start on
>converting NetBSD's userspace, all before the kernel is touched.

I wrote a poll() emulation on top of select (I did not implement all
the features of poll, only the ones supported by the select interface),
which is in use by compat_sunos and compat_svr4.  You can look in the
kernel sources for it. I don't think that writing select in terms of
poll or poll in terms of select is that difficult.

christos