Messages in this thread | | | Date | Wed, 05 May 2004 19:58:03 +0800 | From | Michael Clark <> | Subject | Re: Read from file fails |
| |
On 05/05/04 18:54, Denis Vlasenko wrote: > On Wednesday 05 May 2004 13:19, Libor Vanek wrote: > >>>Libor Vanek wrote: >>> >>>>OK - how can I "notify" userspace process? Signals are "weak" - I need >>>>to send some data (filename etc.) to process. One solution is "on this >>>>signal call this syscall and result of this syscall will be data you >>>>need" - but I'd prefer to handle this in one "action". >>> >>>My first thoughts are to make it a blocking call. >> >>You mean like: >>- send signal to user-space process >>- wait until user-space process pick ups data (filename etc.), creates copy >>of file (or whatever) and calls another system call that he's finished - >>let kernel to continue syscall I blocked >>? > > > I think he meant that userspace daemon should do a blocking syscall > (a read for example). When that returns, daemon knows he has > something to do.
Much like coda already does IIRC - kernel wakes userspace blocking on a read to your special device, userspace 'writes' result back to special device. This was an idea for a generic userspace upcall mechanism originated by Alan Cox with his psdev circa 2.0/2.2 ?? which formed the basis of the coda filesystem which does close to what you would want.
I've written a userspace block device driver interface using this mechanism also (unpublished as of today, not wanting to compete with nbd and enbd - it is unlike enbd which blocks on an ioctl and far far simpler.
http://gort.metaparadigm.com/userblk/
This way to do zero-copy by using mmap on your special device (which I plan to do for my userspace block device interface).
~mc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |