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