On Tue, Aug 23, 2011 at 01:56:04PM +0200, Bernd Petrovitsch wrote: > > We need to make more noises on the *kernel ml* about it > > if we want to ever have non-racy nonblocking read and write. > > > > My last attempt was here: > > > > https://lkml.org/lkml/2007/8/14/135 > > > > https://lkml.org/lkml/2007/8/19/43 > > > > I guess a better kernel patch would really help a lot, mine was > > a very dirty hack... > > FullACK;-) > > It gets now somewhat off-topic, but: > > Ignoring all possible efforts and work, isn't the (best?) solution to > a) add a recv() and send() function pointer to struct file_ops similar > to read() and write() with an additional flags parameter. > b) used recv()/send() in the core if available. Otherwise use the > read()/write() ones (like now). > c) move all read() and write() implementations to the recv() and send() > killing all uses uses of filp->f_flags in the drivers. > d) teach checkpatch at al. that. > e) Remove the read() and write() function pointer.
No, the read and write function pointers are already rather obsolete/deprecated. Using them results in buggy behavior with readv and writev - for example, readv will call read multiple times, once for each iov entry, and each time there is the potential to block. This contradicts POSIX which says the behavior shall be the same as a single read except for where the data is stored, and it actually leads to nasty bugs trying to use readv with terminal devices. I believe the modern functions that support aio and readv/writev could already provide a send/recv-like interface. Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
