Subject: Re: More Device Properties
To: None <firstname.lastname@example.org, email@example.com>
From: None <firstname.lastname@example.org>
Date: 02/14/2001 20:19:26
Sender: Ben Harris <email@example.com>
On 14 Feb 2001 firstname.lastname@example.org wrote:
> Device locators are specified in config files and are completely
> dependent on the that config file. With the current scheme locators
> are used during attach, but not passed to the driver and not kept after
> the attach. That information is required when trying to extract a device
> tree for a config file from a running kernel. If the locators were then
> associated to the device nodes as properties during attach that information
> would be available later.
It's already been suggested that we should add an int *dv_loc to struct
device, which would be a lighter-weight way of doing this.
Probably would be lighter weight, but also not useful for anything
> Also, if you use an array for locators, there is the issue of associating
> the locator value with the locator type. You would need to provide two
> arrays, one of the locator values and another of locator names.
Like the foocf_locnames arrays already built into ioconf.c?
> an array of locators is a specific fix which does not solve a full array
> of problems the way device properties does.
I'd like more examples of that array.
> I'm still unconvinced that all this extra code (which has to be compiled
> into the kernel even if nothing uses it) is worthwhile.
> This actually provides for potential reduction in code. The current MI
> device scheme requires different bus-specific glue code to handle different
> bus-specific attach arg encodings. Device properties are standard, and do
> not require special decoding. By switching to Device properties, the
> bus-specific attach routines could be generalized and reduced to a single
> attach routine. This could result in substancial savings in kernel space.
Hmm. That aspect of it seems interesting. So would your hope be that for
most bus attachments, you could get away with the bus-specific attach code
disappearing entirely, because all the busses would effectively provide
the same attach_args?
No, they would not provide the same attach args. They would provide
a set of named properties. The probe/attach routines would query for
those named properties. If the parent does not provide the properties
required by the child, the child will not (cannot) attach. The child
can query for different combinations of properties until it gets enough
of them so it can attach.