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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Feb 2009 23:28:48 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export device_add_attributes() so drivers can use it.

On Fri, Feb 20, 2009 at 16:28, Grant Likely <grant.likely@...retlab.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@...y.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/