If I understand this correctly, then I am assuming that since the struct
file *file can be NULL, then the struct inode *inode address will always
be assumed to be available from page->mapping->host instead of
dentry->d_inode? Knowing that callers may pass a NULL strut file * is
useful to know.
Thanks.
:-)
Jeff
Jamie Lokier wrote:
>
> Roman V. Shaposhnick wrote:
> > > May I humbly suggest you name the argument `struct file * file_or_null',
> > > so that filesystem implementors don't make the mistake of assuming it
> > > is always set?
> >
> > Hm, I guess that what we need is somekind of documentation on this topic,
> > just to prevent further discussion of what adress_space_operations should be.
> > I bet that after a while there will be a lot of people asking just the
> > same questions and suggesting just the same that will "make things more
> > general".
>
> <rant (for no particularly good reason)>
>
> Do bear in mind that documentation drifts out of date quite easily; when
> it is there, it isn't always easy to find, and many people code based on
> other examples of code instead of looking at the documentation.
>
> In particular, although there are lots of books on Linux subsystems, how
> many device/filesystem authors do you think have ever read one of the
> books?
>
> That leaves Documentation/filesystems/vfs.txt as the obvious place to
> look for VFS documentation. But current file_operations and
> inode_operations structures have different members, and different
> arguments for the existing members. Locking requirements are rather
> unclear.
>
> And vfs.txt doesn't state important things like "your read & write
> methods may be called concurrently -- so device drivers providing read()
> and write() operations may need to use a semaphore to protect access to
> critical device registers". Things that older drivers didn't need
> (AFAIK).
>
> People like me who are good at grepping find answers to these questions
> easily enough, but most driver writers I've seen seem to just copy code
> from other drivers, often old ones, on the assumption that it's correct.
> If something doesn't compile, try to fix up the obvious syntactic
> change. Which may work apart from races or corner cases. Same for
> filesystems. Ah well.
>
> </rant>
>
> -- Jamie
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:18 EST