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

From: Roman V. Shaposhnick (
Date: Thu May 11 2000 - 11:43:59 EST

On Thu, May 11, 2000 at 05:17:16PM +0200, 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).

  My reply will be as always: "Use the source, Luke, use the source" ;)
  Or when in trouble ask people who knows. fsdevel is your friend.

> People like me who are good at grepping find answers to these questions

  Of course, that's why I'm not worrying. At least we have a strong guardian.
  We all know, him, I hope :)

> 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.

  We can't protect people from doing stupid things. At all.

> 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.


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