Messages in this thread |  | | | Date | Sun, 13 Aug 2000 01:28:29 -0400 | | From | Rob Landley <> | | Subject | Re: NTFS-like streams? |
| |
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/
|  |