Re: [PATCH] Export device_add_attributes() so drivers can use it.

[Grant Likely <grant.likely@secretlab.ca>]

Thanks, this is exactly what I want.  I'll read through and write up a
little blurb to describe the recommended model.

g.


On Thu, Feb 26, 2009 at 3:28 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Fri, Feb 20, 2009 at 16:28, Grant Likely <grant.likely@secretlab.ca> wrote:
>> Thanks for the reply, it clarifies a lot.  It sounds like this really
>> should be documented (in Documentation/driver-model/device.txt?).  I'm
>> happy to add a blurb to that effect and send a patch, but I want to
>> make sure I really understand the model before I do so.  I've got a
>> couple more questions below:
>>
>> On Thu, Feb 19, 2009 at 4:08 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> [...]
>>> If an attribute is not available at event time, nothing of this can
>>> ever work. If you look a the device a second later, you will see the
>>> proper looking files and values, and all the test programs will work,
>>> but it will always fail at device creation.
>> [...]
>>> That all might not be needed for your specific setup/driver/device and
>>> may work fine for your need. But we don't want to encourage anybody
>>> with another new API which creates the usual trouble we need to fix
>>> later.
>>
>> Fair enough
>>
>>> And we need to fix things like this all the time.
>>
>> Can you point me at a 'textbook' example of one of these fixups?
>
> Here are a few cases of broken atribute timing, a quick git search has found:
>  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f7120a4f75168df3c02efacd10403a4ba0bcb29d
>  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8a89efd18aa15bb832778baa4e6eee3857ecada4
>  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b23dd6f8a718e5339de4f7d86ce76a078b5f771
>  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e5f10e4f0a9649186d8a8c793822b2e0dae8373
>  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=bfd129445f23c037d9a440ebfa4109e11c220301
>
> Regarding the split of the driver device and the device to bind to:
> the platform stuff is kind of "special", because it is often used for
> devices/buses which can not be enumerated. With buses which need
> enumeration, it's pretty obvious that the enumeration creates their
> own devices, which then a driver can bind to, and where the driver
> creates its own driver instance for it. Like nobody would expect a
> network driver to add the netif properties directly to the pci device,
> and so on.
>
> Many platform devices are just static placeholders, and then it is not
> obvious that userspace still prefers another device instance while
> binding a driver, but in most cases it's worth the effort, because
> then all devices, regardless which bus is backing them, can be handled
> the same way with a "hotplug handler" like udev.
>
> Thanks,
> Kay
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.