Subject: Re: Device Properties: The Next Generation
To: None <>
From: Chris G. Demetriou <>
List: tech-kern
Date: 03/04/2001 00:29:38
so, i thought about this some more today.

A couple of additional thoughts (I've not yet read the replies; i'll
try to get to them tomorrow):

(1) the 'negative size' thing, as a transitional measure only, seems
more reasonable on further consideration.

It means that bus drivers' submatch functions can probably keep their
arguments as-is during the transition... but they need to know what
they're getting.  I don't see how transitional print fns can stay the
same; they just don't have enough information in their arguments to
tell the difference (do they)?  (It doesn't solve the problem, tho --
maybe that means that the submatch & print fns should get changed

New-style devices should still have match/attach conversions, so that
the conversion from "void *" can be done easily later (& parent

Some part of me says that submatch & print fns should be declared
using macros to...  but this is one of those things where #busses <<
#devices, so maybe not.  It would help with a 'flip the switch and it
works new-style or failes to compile' test tho.

(2) the new-style functions should probably convert submatch & print
functions to take non-aux args.

(3) the whole "properties being automatically added from locators"
needs a _lot_ more thought.

For instance, for direct-config devices where you have to call lots of
match functions, trying to automatically set properties from locators
means you may end up setting properties a bunch, or even dozens of
times.  This seems ... quite excessive.

It also raises the issue of 'default value' vs. 'no value'.  For
instance, if you've got a potential vector of i/o addresses/sizes, you
really don't want to include properties for the case where 'no value'
is specified.

Finally, things which actually look at properties "later" don't really
care what the config-file-specified locators are, just the ones that
were actually used to attach the device.

To be honest, this gets me thinking about separate property
containers, so that when it's time to make properties automatically
generated from config info, there's a good place to attach them.