Re: 2.1.118 Tons of oopes
Richard Gooch (rgooch@atnf.csiro.au)
Sun, 30 Aug 1998 20:17:35 +1000
Gregory P. Smith writes:
>
> > > > 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
> ...
> > >
> > > 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.
> ...
> > 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.
>
> Doing some brainstorming:
>
> How about defining a varargs function that takes as parameters
> pointers to the VFS methods in a permanently defined order.
> This way future methods could be added to the end and for drivers not
> using them the function could fill them in with the default action
> pointer. The drawback is that this would need to be done in an
> initialization function.
No, this is exactly what Linus doesn't want, as I now understand
it. The scheme you proposed has the same effect as the one I proposed,
which is to effectively allow driver writers to ignore new methods in
the VFS.
You're probably suffering from the same misconception that I was,
namely that Linus wanted to preserve compatibility. What he wants to
do is highlight to people that the new flush() method exists and
people should consider coding up an implementation where needed. He
feels that any scheme which allows a driver to ignore the new method
results in people not paying attention to the introduction of a new
method, which he feels leads to a maintenance problem. He sees the
best way of forcing people to consider the new flush() method is to
break all drivers and filesystems.
Unless I'm still mistaken, that is his position.
Unsurprisingly, I don't agree with such forceful measures: I'd rather
just announce the new method and tell people what it does and why some
drivers/filesystems may need to implement it. But I'm not making the
decisions.
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