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.
pgp3IhHedgsuI.pgp
Description: PGP signature