Re: [PATCH] int (*readpage)(struct file *, struct page *);

From: Jeff V. Merkey (
Date: Thu May 11 2000 - 11:04:15 EST

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.




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
> Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:18 EST