Re: 2.1.118 Tons of oopes
Richard Gooch (rgooch@atnf.csiro.au)
Sat, 29 Aug 1998 21:30:39 +1000
H. Peter Anvin writes:
> Followup to: <199808290218.MAA28352@vindaloo.atnf.CSIRO.AU>
> By author: Richard Gooch <rgooch@atnf.csiro.au>
> In newsgroup: linux.dev.kernel
> >
> > Before I get into the part about the flames, I have a suggestion: how
> > about we start using the GCC intialiser extensions? In other words, if
> > I have a "xyz" driver, I do this:
> >=20
> > struct file_operations xyz_fops =3D {
> > open:xyz_open,
> > read:xyz_read,
> > write:xyz_write,
> > };
> >=20
> > if I only implement those 3 methods. This is insensitive to members
> > being moved around and it seems to me that it solves the problem which
> > Doug explained which is if you don't carefully look at the structure
> > declaration beforehand, you're stuffed.
> >=20
> > Is this the way you'd like things to be done? This appears to be quite
> > maintainable.
> > If so, it seems to me it would make sense to change all the drivers
> > over to this method. Would you accept a patch that does this?
> >=20
>
> IMNSHO, the whole usage of NULL silly. Is there a good reason why
> we're not simply a pointer pointing to a routine implementing the
> default action? (Does nothing if empty?) That way we wouldn't have
> to have a null pointer check on every call...
Yes, I can see the benefit of avoiding the NULL check. It would be
nice to be able to do this. However, that would then require every
driver to be updated on every addition of a new VFS method.
Is this something we really want? Imagine the horrible code that would
require for a package like PCMCIA: you would have a series of #ifdef's
for kernel versions where the VFS interface has been changed/extended.
However, if there was some compiler trickery we could employ such that
a VFS change doesn't require source code to be touched, it would be a
good idea. Being able to strip those method existence tests would make
code a bit more readable and would also save a few cycles. But I don't
see how to do it without making drivers not distributed with the
kernel much harder to maintain.
Regards,
Richard....
-
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.altern.org/andrebalsa/doc/lkml-faq.html