Mo McKinlay wrote:
>
> # Okay, per-program ways of doing this that don't share code and databases
> # are a bad idea, I agree. But that still doesn't mean it can't be done
> # in userspace via generic shared libraries, or that keeping track of this
> # information in kernel space is necessarily the way to go. Are you
> # objecting to the lack of code re-use, or to the fact that too much is
> # being done in user space?
>
> Well..considering that this stuff is already supported in three of the
> filesystems Linux supports (although Linux itself doesn't), it makes
> reasonable sense that this stuff should go kernel-side. Even if the more
> generic stuff lies in userland, you've still got to have kernel-side stuff
> in order to handle existing filesystems' implementations.
Only if we're going to actually USE the data. Otherwise, mtools like
utilities for when we have to fiddle with this data for the other OS's
benefit (archiving it, etc) make about as much sense to me.
And even if we do have some wierd ioctl or whatever in the NTFS
implementation to read their resource fork data, that doesn't mean we
have to pollute the generic VFS code with the concept of resource forks
if we're not actually going to use them. (How many other OSes do this
multi-user? Do ANY two of them store the data in a remotely similar
format, or even have data with conceptually similar meanings?)
Right now, when this data exists we're basically not touching it at all,
which seems to be the easiest way to stay out of trouble. Maybe not a
GOOD solution, but how much of an actual problem has it caused so far?
(As for Linux desktops trying to make use of other OS's resource
forks... Ew. Just ew. When I was discussing user space I was thinking
if one of our desktops needed (and I mean really NEEDED) a mechanism
like this to associate extra data with files (for icons or executable
behavior or whatever), what would be the least evil way we could do it
(have the desktop maintain its own data in userspace and use inodes to
track the files that data attaches to, no kernel hit at all and no
random scattering of data outside the user's home directory). Since
they've managed to get along without such a mechanism so far, the case
for them really needing it is still to be made...)
Rob
PS to Al Viro... Rio? The mp3 player? It has a desktop?
-
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