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.

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


> 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)


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,

	* 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

	* 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.


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.

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?

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?

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.



cgd