In article
<cs.lists.linux-fsdevel/[EMAIL PROTECTED]>
you wrote:
> On Thu, 25 May 2000, Erez Zadok wrote:
>> (3) if we pass a struct file to ->truncate instead of a dentry, very little
>> change will be required to actual file systems. The changes to the VFS
>> may not be simple however. My quick inspections showed that
>> notify_change and friends don't have an easy access to a struct file.
>
> Except that struct file may not exist. Period.
Fine. This is ok as long as no other filesystem stores stuff in a struct file's
private data. If/when NFS starts storing the filehandle in there, setattr()
*will* need to have access to that struct file.
Until then, we can fake the struct file for our needs...
>> Comments?
>
> You are doing something _very_ wrong. Notice that ->truncate() is actually
> a helper - we shouldn't have it in inode_operations at all and that's on
> a hitlist.
Indeed, what Erez really meant was setattr(), not truncate().
> ->setattr() _is_ a method, all right, but there is no struct
> file around the bloody thing. Moreover, for stuff like devices ->setattr()
> is fundamentally _non_-file animal - file_operations are from the
> device driver, inode_operations are from the hosting fs. ->setattr()
> belongs to the latter.
[ For the sake of keeping things simple, interpret truncate() as "setattr()
called with ATTR_SIZE" in the lines below. ]
But here is the fundamental problem we are facing. There are cases when
the truncate() method of the stacking filesystem needs to do something
*very* different from what the truncate() method of the stacked filesystem
would do. So it needs to do some data munging on its own. However, all the
methods that give access to a file's data -- read(), write(), readpage(),
writepage(), prepare_write(), commit_write() -- *require* a struct file to
be passed as one of the parameters.
See now the problem we are facing here?
By the way, this whole discussion around truncate() might only prove that
the recent move from passing struct dentry to passing struct file to some
of these methods was a mistake. Essentially, if a filesystem needs access
to a struct file in order to do data manipulation, it will get royally
screwed as soon as truncate() is called.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
