lkml.org 
[lkml]   [2000]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:58    [W:0.029 / U:1.472 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site