Subject: Re: Adding video mode info to struct wsscreen_descr
To: None <cgd@broadcom.com>
From: Gary Thorpe <gat7634@hotmail.com>
List: tech-kern
Date: 07/10/2002 22:29:10
>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