Re: Read from file fails

[Michael Clark]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/