On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote:
> * Kostik Belousov <kostik...@gmail.com> wrote:
> > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote:
> > > * Kostik Belousov <kostik...@gmail.com> wrote:
> > > > Which most likely means that fusesfs filled its own struct fileops
> > > > without properly initializing fo_truncate member.
> > > 
> > > It's a bit misleading that cdevs automatically patch the table, while
> > > the fileops don't. Maybe it would be a good idea to patch finit() to
> > I do not understand your first sentence. Would you please elaborate ?
> 
> Say, you create a cdev, if you don't implement all ops, it will check
> for null pointers and return error codes accordingly. This doesn't
> happen for fileops, which is probably one of the reasons why people
> sometimes forget to implement them.
> 
> Wouldn't it be better to prevent this form of footshooting by adding
> assertions? This will add some overhead for any file descriptor created,
> but a kernel with INVARIANTS isn't meant to be fast.
Thanks, I see it now.

The cdev interface definitely falls into the public kernel interface.
Having to fill all cdevsw methods for a random driver is too much
burden put on the several dozens maintainers.

On the other hand, file level is not much widely used by third-party
components, and even in-tree code implements only ten different file
types.

I would not object loudly if someone put such checks as proposed
under INVARIANTS, but also I do not see a real point in having them.
Might be slightly better to put the checks, again under INVARIANTS,
in the fo_XXX() wrappers.

Attachment: pgp3IhHedgsuI.pgp
Description: PGP signature

Reply via email to