On Wed, 7 Mar 2007, Eric Dumazet wrote:
>
> sockets already uses file->private_data.
>
> But calls to read()/write() (not send()/recv()) still need to go through the
> dentry, before entering socket land.
Sure. The dentry and the inode need to *exist*, but they can be one single
static dentry/inode per "file descriptor type".
We always pass in the "struct file *" to read/write too, since we need it
anyway for things like file control information (eg "is it a nonblocking
read or write" kinds of things).
So I'm not suggesting a NULL dentry/inode, I'm suggesting a single static
one per type.
And yeah, it may be harder than it looks. Some things "know" that all the
relevant info is in the inode, so they just pass in the inode. In the pipe
layer, for example, you'd need to change free_pipe_info() and
alloc_pipe_info() to pass in the file descriptor instead, same goes for
pipe_release(). But the "struct file *" is always available, it's just
that since the code was originally written to have all the info in the
inode, some of the code isn't set up to use it or pass it on..
But your patch is independent of that, and looks fine. Except I don't like
this part:
- file->f_path.mnt = mntget(sock_mnt);
+ file->f_path.mnt = NULL;
since I'd be much happer with always having f_path.mnt available, the same
way we should always have f_path.dentry there.
(Btw, your patch is *not* going to work with the file->f_private_data
approach, because d_path() is not passed down the "file *" thing. So we'd
need to do that, and that's more intrusive (it can be NULL, since for
things like cwd/pwd we don't have a "struct file").
But I like your patch as a totally independent thing. "It just makes
sense".
(Apart from the f_path.mnt thing, which I think was something else ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
