On Tue, Mar 22, 2011 at 11:12 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>>
>> Why don't you just pass in the filp to the ->open routine, and drop
>> that "flags" argument. Maybe other filesystems want to use ->open, but
>> don't want to put_filp() on the filp we already allocated, only to
>> allocate a new one?
>
> Maybe, although I don't see the reason to do that. Why keep the
> original one? It doesn't contain any information besides the flags
> and the dentry/vfsmount.
Umm? Because that way you can avoid allocating a new one?
So let's turn your questions on its head: why do you insist on
free'ing the old one, WHEN YOU KNOW THAT THE ->open ROUTINE NEEDS TO
ALLOCATE A NEW ONE?
Sure, in _your_ case, you'll get a new filp because you're going to do
a whole new open of a lower-level filesystem, but if the ->open
routine is all about just your case, then I don't want it as a VFS
layer operation. So for your filesystem, you will always discard the
old one as useless. But that's purely an implementation detail for
you. It has nothing to do with the VFS interfaces.
So why do that idiotic free, only to force the callee to then
re-allocate a new "struct file"?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
