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/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:18 EST