>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 22:40:35 -0700
>
[...]
>
>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?

An ABI should be independent of the underlying implementation i.e. the 
actual layout of the device's soft configuration data. As you go on to say, 
which I agree with, is that you need to use function calls to create an ABI. 
These function calls would have to be stable and be consistently available 
to the run-time linking agent. However, what these functions do to soft 
configuration data is implementation-specific. I.e. the actual layout of the 
soft configuration data should not matter as long as the device provides the 
same ABI which would make nested structures irrelevant.

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

I agree. Currently, none of the OSes that have seemless or semi-seemless 
module support (Linux and FreeBSD) support stable kernel module ABIs as far 
as I know. I remember having to recompile pcmcia modules if I recompiled the 
*same* Linux kernel version with APM or SCSI (2.0.x series). FreeBSD always 
rebuilds the modules with the kernel. Maybe the problem is that the source 
is readily available??? Perhaps if the source were not available as in most 
commercial system, it would force an ABI to be developed?

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

True. Unfortunately, functon calls are considered "bad" by some programmers 
concerned with performance. I don't think it is much overhead (even on older 
machines), but if it is a very frequent call it will add up. Gain: ABI, 
loss: some slight performance.

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

Blame the person who failed to document the struct. Having an undocumented 
ABI won't be of much help either though, so is this a valid point?

[...]
>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.)

No, we don't know the answer. To ascertain this, we would have to profile 
device access for all netbsd drivers to see what they are doing. However, 
since most devices probably only use this info during autoconfiguration, you 
are probably right. During this process it is also very reassuring to know 
that all devices' soft configuration can be treated as struct device and 
that the hierarchy is stored using this structs.

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

My whole point is that nesting struct device should not make a difference 
since it would be abstracted (hidden) away anyway by the ABI.

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

Yes. Making the whole argument moot.

>
>
[...]
>
>_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

No, the current interface doesn't need to *change*...it needs to be created! 
There is no standard ABI for NetBSD kernel modules, user programs, kernel 
interfaces etc. as far as I know.

OOP is just for modeling purposes. "Base class" is just a nice way to think 
of it. I am in favour of modularization actually but the fact is that OS 
designers/hackers favour monolithic systems and all the associated problems.

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