[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A little help for GWorkspace

From: Enrico Sersale
Subject: Re: A little help for GWorkspace
Date: Fri, 12 Jan 2001 17:02:15 +0200 (EET)

On Fri, 12 Jan 2001, Helge Hess wrote:

> Enrico Sersale wrote:
> > I already know all this, but:
> > 
> > I was thinking that that Irix deamon take control of all the file
> > system, without asking them...
> To be true I don't understand that question/statement.
> Are you trying to say that the Irix daemon always watches all files and
> always broadcasts all changes to all clients ?
> I can imagine that the Irix daemon has some fs-change support from the
> kernel, but AFAIK the only portable way to find changes is to
> periodically stat the files. This is only usefully possible if you
> restrict the watch-set.
> Helge

Some days ago, I've read, on a kernel related list, the following
I hope that this will clarify why I've thinked so. 

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]