> Dale Amon writes:
> > I'd love to see the like under Linux as well. In USER
> > land. There is very little that has any place in the
> > kernel. One exception is an item on another thread:
> > a signal that tells you when a file is written. That
> > is very useful, perhaps essential, for NeXTstep type
> > GUI's.
>
> There's merit in that idea. It's in keeping with the principle of
> having the kernel export information it has to keep anyway to user
> space so that user space doesn't have to waste resources regenerating
> this information.
>
> You could probably do this in the VFS layer. Just add a new member to
> the VFS inode structure which is some kind of communication channel to
> a process. If the channel is open, send a message in sys_write().
>
> The channel could be a pid to send a signal to or a file pointer to
> write data into. You'd set up this channel using fcntl().
>
> This scheme would work for all file types: directory, regular, device,
> whatever. The only cost would be an extra test in sys_write(), which
> is relatively cheap, since the common case would see the test
> fail. Certainly cheaper than the global kernel lock that we're
> planning on chucking.
>
> Hm. You could add interception points for other VFS methods too, like
> read, lookup and more. Might make it easier to implement direct mount
> automounting.
My dream for a while was also to be able to trace what particular blocks
(and from which files) are read off disk. This would allow for existence
of a user-land application that speeds up disk access (for example a big
program faults in different places in its file and reads different
configuration files on startup. this pattern does not change - bc
unless the program initialized nobody can interact with it and alter
the pattern)
Vladimir Dergachev
>
> Linus: is this an idea worth pursuing?
>
> Regards,
>
> Richard....
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/