[lkml]   [1998]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Suggested changes to the VFS
    >>>>> "HA" == H Peter Anvin <> writes:

    HA> Incidentally, open is defined as a file_operation, which IMO
    HA> is bogus, since you can only open() an inode, and the open
    HA> function is passed an inode anyway. It would appear more
    HA> logical to me to move open to the inode_operations structure.
    >> Perhaps it's the name that's bogus and misleading?

    HA> No, I don't think so. Your message doesn't really parse to me, so
    HA> maybe I'm misunderstanding, but it seems very weird that open() is
    HA> considered a file descriptor operation when it is fundamentally a
    HA> constructor for a file descriptor.

    A constructor for a file descriptor should not be a file descriptor
    operation? Though I admit there is a bit of a chicken and egg problem

    HA> Incidentally, open() *always* gets
    HA> its file descriptor operation from the inode operations immediately
    HA> before calling it.

    Yes, and f->open is allowed to override those.
    I haven't seen anything that actually overrides the file operations

    HA> I think open should be allowed to return a reference to an already
    HA> existing file descriptor if it wants to; it doesn't seem that major of
    HA> a change if a canned routine is provided to do what the pre-open
    HA> initialization code does.

    What would be the advantage to returning an already open file
    descriptor? All file desriptors are the same size. And open is
    maintained per call to open. And on only a few occasions can they be
    shared: dup, clone(CLONE_FD)

    So what is the gain? Besides breaking file descriptor semantics?

    Or are you thinking for /proc/pid/fd directory? I guess I can
    see a need to return a prexisting filedescriptor there. But I still
    think that is debateable.

    If you allow an open with the semantics you suggest you should still
    have a functions that are equivalent to the current open, and release
    functions so that code that uses them, can still work, with minor

    Just as a reference point I have code currently that uses the current
    open and release methods on a directory inode. They store in
    f->private_data the next name to return from readdir.
    Essentially the directory file position. But since I have directories
    as trees instead of flat files, this improves performance and makes my
    life simpler.

    Does that parse better?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

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