| |||||||||||||
|
| |||||||||||||
Choosing between portability and innovationChoosing between portability and innovationPosted Mar 3, 2011 20:24 UTC (Thu) by clump (subscriber, #27801)In reply to: Choosing between portability and innovation by wahern Parent article: Choosing between portability and innovation
The problem with BSD cooperation is that Linux (and Linus) don't like to cooperate.The article does a good job of articulating issues with resource constraints and rapid pace. You've mentioned functionality, but nothing to support the accusation that "Linux" doesn't like to cooperate.
(Log in to post comments)
Choosing between portability and innovation Posted Mar 4, 2011 14:37 UTC (Fri) by trasz (guest, #45786) [Link]
Kqueue vs epoll is a pretty good example of lack of willingness to coooperate - kqueue was earlier, yet Linux folks chose to implement something incompatible and functionally inferior.
Choosing between portability and innovation Posted Mar 4, 2011 20:59 UTC (Fri) by nevyn (subscriber, #33129) [Link]
kqueue is a _huge_ interface, combining a number of ideas, you basically need to design your kernel around it if you want users to use it. And much like SYSV streams, expecting other people to reimplement a giant redesign like that is often expecting _way_ too much.
On the other side, timerfd(), socketfd() and epoll() are all there to do a single thing. FreeBSD did the retarded thing when they reimplemented sendfile() roughly a week after Linux added it. TCP_CORK is still not implemented in FreeBSD. mremap() was NAKd, there's the whole MMAP_ANON vs. MMAP_ANONYMOUS, or the weird bits of mmap in general.
Cooperation is much more like to happen in the FreeBSD => Linux direction, IMO ... but that could also just be the much bigger developer pool.
Choosing between portability and innovation Posted Mar 9, 2011 14:48 UTC (Wed) by mheily (guest, #27123) [Link] Actually, you don't need to redesign your kernel to implement the kqueue API on Linux. The libkqueue project provides a userspace wrapper library that translates each kevent() call into the equivalent epoll/inotify/timerfd/signalfd/etc call for Linux. On Solaris, it uses the event port framework. On Windows, it will use the WaitForMultipleObjects() function.(Disclaimer: I am the main author of libkqueue)
Choosing between portability and innovation Posted Mar 9, 2011 20:52 UTC (Wed) by nevyn (subscriber, #33129) [Link]
My biggest concern with doing something like that would be how efficient it is compared to using the native interface (and why I said you'd need to redesign the kernel, so that it could be implemented efficiently), the only benchmark you have is vs. poll() (and uses ab) ... which is pretty sad.
epoll <=> kqueue is probably the best case test too, to be convincing you'd want something that benchmarked EVFILT_VNODE/SIGNAL/TIMER at least. To be really convincing you'd want PROC/USER/AIO and play with the EV_* flags.
|
|
||||||||||||