> CDs @ http://www.cruzio.com/~billpeet/MusicByCandlelight
> On Fri, 28 Aug 1998, Richard Gooch wrote:
> > David S. Miller writes:
> > > Date: Thu, 27 Aug 1998 07:25:34 +1000
> > > From: Richard Gooch <rgooch@atnf.csiro.au>
> > > Definately not! But if flush() was appended to the structure, then
> > > people had only to recompile their drivers and all would be fine. So
> > > there would be no silent failures in that scheme.
> > > ...
> > > So please explain where the benefit of placing flush() in the middle
> > > is?
> > > So that people don't "only recompile their drivers" and the driver
> > > code actually get updated and fixes done by or sent to the maintainer!
> > Sigh. Maybe people don't understand my question. Let me ask it another
> > way: did you want people to go in and manually insert NULL for the new
> > flush() method and then go and recompile? If so, how is that better
> > then automatic structure initialisation to NULL?
> > If not: what did you want people to do? Write a flush() method? In
> > that case, where was the announcement of the need for every driver to
> > now implement a mandatory flush() method?
> I have seen similar cases where the do-ops code deliberately had null
> entries at the end so that new methods could be added without requiring
> recompilation. That scheme also had a "version" number which each method
> could check, thereby allowing a driver to support multiple levels of the
> driver system.
The padding I've got mixed emotions about. How much is enough?
Doesn't that really encourage lazy programming techniques? I really
don't think I could support a design decision like that if one of my
engineer's proposed it...
Now the versioning is another matter...
I've seen this done (and done it myself) in numerous API's. You
bury a "magic number" and a "verion" in the structure somewhere as a
sanity check in critical areas of the code. Then you can chose to
raise holy hell when you get fed a bad structure or muddle along as
you best you can. I did an entire voice command API this way where
the user applications were only given an opaque object (that was a pointer
to the passed-around structure). Works wonders for debugging and
sanity checking when you DON'T control everything coming to you.
Up side is that you are not dependent on highly unreliable
compiler warnings (not even fatal errors) as in the current case.
Down side to this is that it does take a little overhead in
checking the structure codes and version. It would also really REALLY
bust the bejesus out of the current structure and drivers to retrofit
something like this. At this point, unless Linus is looking at doing
this to us on a regular basis (A JOKE, Linus!), it probably isn't worth
the pain and suffering that would result...
> john alvord
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- 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