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

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site