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
> There are two parts to the open process.  Getting the dentry and inode
> with lookup, which can do everything you want. And opening a file
> descriptor, which provides a nice handle for the file. The later case
> is what open is for.
>
> Currently I use open to reserve storage via struct file f_private_data
> to hold my place (in non-linear directory files). And release is what
> I use to release that storage.
>
> 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?

No, I don't think so. Your message doesn't really parse to me, so
maybe I'm misunderstanding, but it seems very weird that open() is
considered a file descriptor operation when it is fundamentally a
constructor for a file descriptor. Incidentally, open() *always* gets
its file descriptor operation from the inode operations immediately
before calling it.

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

-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.046 / U:0.828 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site