Re: Integration of gmc and nautilus desktop directories.

[Owen Taylor <otaylor redhat com>]

Alan Cox <alan redhat com> writes:

> > > A five to ten second delay between mounting a volume and having an icon
> > > representing the mount appear on the desktop
> > > is simply unacceptable.
> > 
> > well, it depends on how one is mounting the partition.
> 
> It taks at least 2 seconds for magicdev to do a CD mount. Twenty reads of the
> file a second is ugly. Thats in the 'so run KDE' category in my book. Its
> enough to prevent APM hitting anything but the most basic power saving, and
> on a standard configuration because you open the file each time it will keep
> the disk spinning.
> 
> At the very least you should stat the file and check for a ctime/mtime change
> to have occurred - and you might as well do that once every 2 seconds. That
> will avoid an atime update and a disk write.

/me quickly fixes magicdev before Alan notices. 
 
> > notification from the kernel would still be much better, if you know
> > what i mean.
> 
> The kernel should not be involved. Fix the gnome mounting tools and mount to
> provide notifications. Every mount is initiated in user space therefore the
> kernel is the wrong place for this. System service != kernel.

The difficult part here, to some extent, is not the kernel/userland
split, but the system/user part.

There is simply no good, standard way for something running as root to
notify to notify a programming running as a user that an event
happened.

It certainly is conceptually feasible to have a central server for
this purpose that interested clients can connect to and register
interest in events. For one reason or another, this has never happened
-- perhaps because a solution that was general enough to satisfy
everyone would be too complicated to satisfy anyone.

Currently, the only real way is the one that magicdev takes - the system
modifies a file, the user polls and notices the changed modification
time; with the Linux 2.4 kernel notification code, the poll could,
in theory, be avoided.

Avoiding it in practice probably involves writing some glue code that
hides the real-time-signal scariness, provides fallbacks, integrates
with the main loop and so forth.

Regards,
                                        Owen