Tobias DiPasquale wrote: > I was wondering if there was a way to notify userspace readers about > _how much_ data was to be read, not just readiness for a read or > write? poll(2)/select(2) just let the userspace processes know about > whether or not an operation will block, it would seem. Userspace can find out how much data is pending to be read using the FIONREAD ioctl, if your driver provides that operation. See pipe.c However, it seems likely that this wouldn't solve your problem. > The problem at hand is that the data being buffered in my driver is of > different sizes (therefore its a character driver, not a block > driver), but the units are stored in a list where a read request will > return 1 or more of the units atomically (meaning that the whole unit > is read or not). For example, if there are 5 units in the list of > sizes 1000, 2000, 4000, 2000 and 6000 bytes, the process should be > notified that there are 15,000 bytes of data available to be read. > Should the process specify a count of 8192 bytes, for example, the > driver could then only write the first three units of memory. > > Does anyone know of a way to let the userspace processes know how much > data is in my driver's buffer in advance of a read(2) so that it can > avoid blocking and also exhibit the maximum transfer rate from kernel > to userspace? Thanks in advance! :) Your question seems to indicate that you just want to avoid blocking. If that is all that you need, surely it is best to use non-blocking I/O (O_NONBLOCK), and not even use poll/select at all? Then there is no need to know how much data is pending. However, usually when you are doing non-blocking I/O you also have controlled blocking using poll/select, perhaps multiplexing with timers or other fds. I'll assume you are really doing this. If this is the case, then your problem appears to be that poll/select do not block when there is an incomplete data record available from your driver, but the driver will not return an incomplete record via read(). Again, knowing how much data is pending won't help. You need poll/select to block, and in fact they should block: it's a bug in the driver if they don't block when read() won't return a record. If this is the case, the correct fix is to the driver's ->poll() operation, so that it says read won't block when read won't block, not when there's a partial record pending. -- Jamie - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
