>From: cgd@broadcom.com
>To: gat7634@hotmail.com
>CC: tech-kern@netbsd.org
>Subject: Re: Adding video mode info to struct wsscreen_descr
>Date: 10 Jul 2002 18:23:22 -0700
>MIME-Version: 1.0
>At Wed, 10 Jul 2002 18:39:52 +0000 (UTC), "Gary Thorpe" wrote:
> > >At Wed, 10 Jul 2002 02:35:26 +0000 (UTC), "TAKEMURA Shin" wrote:
> > > > You've already use the hack for long time :-)
> > > >
> > > >     struct wsdisplay_softc {
> > > >         struct device sc_dv;  /* <- HERE! */
> > >
> > >There are some who consider that a bug, too...
> >
> > Why is is a bug?
>
>think in terms of e.g. binary kernel modules.
>
>you tweak your 'struct device' contents, say, decide to add a new
>member at the end for some additional bookkeeping information.
>
>oh well, all vendors that built binary modules now have to build them
>again.

Only if the ABI was dependant on device soft configuration structures.

>
>Why?  Because there was a lack of respect for modularity in the kernel
>code.

The kernel code currently is not modular. I cannot turn my device drivers 
into modules without hacking them myself currently.

>
>
> > In FreeBSD there is no such structure nesting and as a
> > result you have to do ugly things to do simple things like get a 
>device's
> > name etc. What would be better?
>
>I can't really speak to features or misfeatures of FreeBSD, but that's
>really not relevant.
>
>Which do you think is "uglier":
>
>	sc->sc_dv.dv_xname
>
>or:
>
>	DEVICE_NAME(sc->sc_dv)
>

DEVICE_NAME() is probably a macro that does the same thing. Doesn't affect 
ABI considerations does it?

>
>Personally, the former gets my vote.  The latter, to my mind, is:
>
>	* more straightforward, i.e., it's more obvious exactly what
>           it's going to give you,

sc->sc_dv.dv_xname isn't obvious?

>
>	* a more flexible API, i.e., you can change how sc_dv is
>	  implemented (its type, e.g. from a struct to a ptr or back,
>	  or change the name of the 'device name' member) without
>	  changing the source to every driver, and

You can change how *sc* is implemented, but sc_dv is a "base class". See 
below.

>
>	* depending on how you implement it, possibly a more flexible
>           ABI, i.e., you can change the underlying storage format of
>           the 'device' structure w/o recompiling modules that use the
>           interface.

The point is, struct device contains information that ALL devices can have. 
In OOP, it would be a base class. Since every single device needs this info, 
it may as well be nested for easy fast access. E.g. struct foo_softc * ptr 
can ALWAYS be casted to struct device * because of this.

>
>
>In practice it doesn't matter much if you've got, say, a crappy module
>system or no vendors producing binary modules for your system.  (Both
>are pretty much true last I looked, for NetBSD.)  You don't typically
>change the way the data is stored, or change the names of struct
>members, very often.

A stable binary API would abstract away these details anyway.

>
>However, one of NetBSD's main goals is to build things "better."
>
>Assume that there _are_ lots of people out there building binary
>modules for NetBSD, and that the module interface doesn't suck...  Is
>this coding style going to cause them a headache?  Is the headache
>worth the benefit?

Modules are not seemless in NetBSD: you have to roll them yourself as far as 
I know.

>
>For that matter, what _is_ the benefit of using the current coding
>style?  For that matter, what _is_ the benefit of the current style?
>It's not IMO as clear as some alternatives...  It's not inherently
>more efficient (you can implement a style w/ a more flexible API with
>exactly the same run-time cost)...  Anybody?

API is not the key: ABI is. This means that not only is the API consistent, 
but the way the glue interacts at run time is consistent.

>
>I think the answer is "the benefit of using it is that unneeded code
>change is bad, so it would be bad to change it without need" But if
>there is any kind of concrete need, or if somebody's going through and
>changing much of the implementation for other reasons (i.e. to get
>unrelated features that require touching much of the same code)... it
>would probably be a good idea to switch.

What does it currently prevent? What does this particular practice 
specifically prevent? I'm just curios and I have no stake in the convention 
being changed or kept.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com