Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: Suggested changes to the VFS | Date | Tue, 24 Mar 1998 16:52:46 -0800 (PST) |
| |
> 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
| |