Horst von Brand wrote:
>
> Mo McKinlay <mmckinlay@gnu.org> said:
> If you can come up with something that currently isn't kept in an
> executable (or whatever) file, and that has to be managed centrally, it is
> probably something that has to be kept out of the file itself anyway: ACLs
> and capabilities are cases in point.
Hence we return to the windows registry (or, this being a multi-user OS,
a per-user registry of some sort). This is vaguely what OS/2 did under
FAT, by the way. Created a file in the root directory, "ea data.sf" I
believe. Hence the 64k limit being filesystem-wide instead of per file
(because the filesystem device drivers were 16 bit).
I'm not sure how much of the windows registry is pure fundamental evil
and how much of it is just really badly implemented. But I -AM- pretty
sure that once you hit that point, this becomes a user space issue. If
gnome wants a file full of data attaching properties like icons to
whatever objects it wants to create to represent files and such in the
system, gnome can maintain it itself.
Where the kernel IS involved is possibly some kind of callback mechanism
you can hook into so you know when the filesystem changes out from under
you (so when your files get moved the icons can stay with them, etc).
Except this might have security ramifications (who can register for
these callbacks, what information do they get), and performance
ramifications (especially if we worry about syncing the callback before
performing the actual operation, which is probably a really bad idea on
a BUNCH of levels), and of course if you're mouting a network filesystem
the file STILL changes out from under you and there's nothing you can
do, so the whole mess might just be a red herring and the desktop is
just going to have to poll or use hardlinks or something similarly evil.
An asynchronous callback as an advisory that a file just moved/was
deleted could be useful to a desktop displaying info about those files.
But that's probably about it, and a similar thing could be done by
polling and keeping track of inodes in a registry file. Beyond that, I
think the Gnome guys (or KDE if you insist) are just going to have to
figure out what they need and THEN come ask for it.
And having the kernel complicate such a basic unix metaphor as a file
without a DARN good reason is just stupid. My opinion, anyway...
Rob
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:29 EST