> > Perhaps one solution is to add an ioctl to set high/low
> > watermarks on a device and add new event bits POLLIN_WM and
> > POLLLOUT_WM for the poll() syscall.
> Good idea, this could solve the blocksize problem rather elegantly
> (although with some portability problems...).
I still believe that this is the responsibility of the driver. If
the driver owns a double buffer instead of relying on system owned
resources only "loaned" to it, then it will be able to be written in
buffer size chunks, or not at all.
This neatly resolves the portability issues, and places the onus
for driver behaviour where it rightly belongs: with the driver.
Screwing with these watermarks still puts the onus on the driver to
allocate the system resources before it can answer your select()
"yes, writeable". Since the onus is there anyway, why make the
programatic interface both more complex (for no visible gain) and
less portable (for no visible gain)?
Any opinions in this posting are my own and not those of my present
or previous employers.