Subject: Re: More Device Properties
To: None <eeh@netbsd.org>
From: Chris G. Demetriou <cgd@sibyte.com>
List: tech-kern
Date: 02/14/2001 11:01:43
eeh@netbsd.org writes:
> Here's an enhanced version of the Device Properties proposal I 
> sent out some time ago.  Some names have been changed to remove
> conflicts with existing MD functionality and enhancements have
> been made for passing properties during probe and attach.

This doesn't seem entirely unreasonable.


> Eventually I would like to deprecate the current aux vector and
> convert all drivers to use device properties.

That's a pretty significant change from the existing behaviour, which
I suspect has some pretty significant impacts on at least memory
usage.  (it does buy some features, though.  It probably also effects
CPU usage during configuration, but that's not worth worrying
about. 8-)

That's something to think about for the future, anyway.


> 2.1	Changed Functions
> 
>    struct device *config_found_smd(struct device *dev, void *aux, 
> 			cfprint_t print, cfmatch_t submatch, 
> 			struct device *propdev);

Technically, this is a new function.  Presumably, config_found() and
config_found_sm() would be macro wrappers around it, right?


>    struct cfdata *config_search(cfmatch_t fn, struct device *parent, 
> 			void *aux, struct device *propdev);
>    struct device *config_attach(struct device *parent, struct cfdata *cf, 
> 			void *aux, cfprint_t print, struct device *propdev)

These should probably be done in ways that preserve
backward-compatible APIs, as was done with config_found ->
config_found_sm, etc.


> 2.2	New Functions
> 
>    struct device *devprop_create(void);
>    void devprop_destroy(struct device *);

I'm not convinced of the virtue of these.  I think if you're going to
create a 'property container,' you should create a propery container,
and embed that in 'struct device'.

Using device structs for this purpose seems a little bit ... lacking.


>    int set_devprop(struct device *dev, const char *name, void *val, 
> 			size_t len, int flags);
>    size_t get_devprop(struct device *dev, const char *name, void *val, 
> 			size_t len, int flags);
>    int del_devprop(struct device *dev, const char *name, int flags);
> 
>    size_t get_mdprop(struct device *dev, const char *name, void *val, 
> 			size_t len, int flags);

These should all be prefixed with a common prefix, just like config_*
are now.

I might suggest something like:

struct devproplist *devprop_list_create();
void *devprop_list_destroy(struct devproplist *);

then use struct devproplist, rather than devices, in the devprop fns.
embed a devproplist in struct device, and use it when appropriate.

I'm not sure I like the extra copying that get_devprop() requires,
either, but I'm kinda ambivalent about that.


It seems that you only intend to be passing 'simple values,'
i.e. nothing where a copy actually has to transform an object
(e.g. increment a reference count or similar)?

If you're going to start passing all auxv info down this way, and want
to be doing (un)loadable drivers, it may be a good thing to provide a
way to mutate on copy...  Not really sure though.  Something to think
about.




cgd