lkml.org 
[lkml]   [1998]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Suggested changes to the VFS
Date
> 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
> there.

It isn't as strange as it sounds. In C++ a constructor is a member
function for namespace reasons, but can *NOT* be a virtual function
for exactly the reasons we're now discussing.

> 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
> though.

What good would that do, though? You would have to call the
overridden function yourself, so the indirect is once again really
meaningless.

> 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.

I'm thinking of /proc/pid/fd, but I'm also thinking of things like TCP
filesystems, and a more reasonable implementation of userfs; passing a
file descriptor down from userspace would really be the appropriate
way to do this.

/proc/pid/fd I find is often huffed at, but from my work on
magicfilter where I have to coax a number of different programs into a
single user interface I know it can be incredibly useful.

Note that copying a file descriptor is a quite different operation
than generating a reference to it.

> 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
> modifications.

Basically, this is what I'm proposing; if this doesn't meet your needs
we'll have to figure it out:

1. Move open from file_operations to inode_operations;
2. Change the current scheme:

reserve a fd number
allocate a file structure
look up the dentry/inode
copy inode->file_operations to the filp
call filp->open
initialize filesystem-specific data
install the file structure with the reserved fd number

To:

reserve a fd number
look up the dentry/inode
call inode->open
call canned initialization routine (if desired)
allocate a file structure
copy inode->file_operations to the filp
initialize filesystem-specific data
install the file structure with the reserved fd number

> 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.

I don't think this change should affect you at all. All the changes
you'd have to make would be to move the open method into the inode
structure and add a call to the file structure allocation subroutine
at the beginning of your open method.

The only issue I can see would be if you would want to override the
file_operations and then call a different open() method. If this
functionality is really needed (I would be surprised if it is, but I
have been surprised in the past) we could pass a pointer to a
file_operations structure down as one of the arguments, with the
standard open routine of course passing the one in the inode.

Would that allay your concerns?

> Does that parse better?

Yes, it does. Thanks.

-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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