At Thu, 11 Jul 2002 02:29:24 +0000 (UTC), "Gary Thorpe" wrote:
> >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.

So...  consider any interface for loadable device drivers.  it would
pretty much ... have to incorporate device soft configuration
structures, eh?

So, those structures currently include, and must include, as their
first element the 'struct device'.

So, any such ABI based on the current interfaces would definitely be
dependent on said structures, eh?


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

Due to various limitations, certainly.  many of them are orthogonal to
this issue.  However, that doesn't mean that the design here isn't an
issue for binary drivers.


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

It may be a macro which does the same thing.  It could just as easily
be a function call.

That's the point: use a well-defined interface, so that implementation
changes like, say, changing an indirection to a function call so that
the ABI will be more suitable can be made without modifying every
driver in the source tree.


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

OK, without looking at device.h, tell us:

What's the 'x' about?  What's the difference between dv_xname and
dv_name?

Now that you've answered that, why _is_ there an 'x' in that structure
member name?

So, in fact, sc->sc_dv.dv_xname is _not_ particularly obvious on a
deeper look, at least when compared to possible alternatives...


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

Why is 'fast access' to said "base class" a useful feature on which to
base the implementation?  I.e., what elements of 'struct device' are
accessed with enough frequency that high performance access to them is
important?

(The answer is "none."  The only _possible_ exception to that is
dv->parent, but if the child is using the parent's resources often,
I'd say it should have a more direct reference to them.)

Is that "useful feature" useful enough that the implementation should
preclude features that others might find useful (e.g., binary
modules).

Note again that there can be implementations using a more modular
interface which perform as well or very nearly as well...


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

... because it would change the direct access to this structure, for
instance.


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

Huh?  That question doesn't make much sense to me.

_Right now_ the existing interface doesn't really cause much problem.
Hence, "don't change it" unless somebody's planning to go through and
modify much of the code anyway.

But, the point is, it's fairly clear that the current interface _does_
need to be changed if you want to provide sane support for binary
modules while allowing the details of the device "base class" (as you
put it) implementation to change.


cgd