Messages in this thread | | | Subject | Re: Suggested changes to the VFS | From | (Eric W. Biederman) | Date | 24 Mar 1998 16:05:57 -0600 |
| |
>>>>> "HA" == H Peter Anvin <hpa@transmeta.com> 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 there.
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.
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 modifications.
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?
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |