At Thu, 11 Jul 2002 13:48:05 -0400, Gary Thorpe wrote:
> An ABI should be independent of the underlying implementation i.e. the 
> actual layout of the device's soft configuration data.

Right.  And, you can't have the 'struct device' embedded in the device
softc and satisfy this unless either:

	* its contents are fixed "for all time," or
	* each individual driver provides "access methods."

both are obviously losing.


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

programmers who are "concerned with performance" also should unerstand
the notion of "frequency of use."  How often do the contents of
'struct device' get used?


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

Or, even without profiling, you can look into the structure and see
what is _possibly_ there that they might want to access, and when they
might want to access it.  I believe i've gone over this already.


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

I don't see why that's any more or less "reassuring" than just chasing
one pointer to get there.

Blind casting, IMO, doesn't increase assurance.


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

Nesting is only OK if every driver provides access functions.  Which
is not only stupid, but it also means that e.g. the "assurance" you
think about above won't be there.

If you've got a nested device strict, how do you, say, double the size
of dv_xname?  How do you add 3 new bookkeeping fields you need?



> No, the current interface doesn't need to *change*...it needs to be created! 

There is an interface.  It exists.  It is not the right one, so it
should change.


> OOP is just for modeling purposes. "Base class" is just a nice way to think 
> of it.

_you're_ the one who's been calling it that; one would hope you like
to think of it that way.


> I am in favour of modularization actually but the fact is that OS 
> designers/hackers favour monolithic systems and all the associated problems.

By all means, try to tell me what I prefer.  8-)



anyway, i'm done with this discussion; it's devolved past the point of
usefulness.



cgd