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]

Message-ID: <fa686aa40902182250g1c4e7cb6o4d0102da35ab838b@mail.gmail.com>
Date:	Wed, 18 Feb 2009 23:50:46 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Greg KH <gregkh@...e.de>
Cc:	Kay Sievers <kay.sievers@...y.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Export device_add_attributes() so drivers can use it.

On Wed, Feb 18, 2009 at 11:39 AM, Greg KH <gregkh@...e.de> wrote:
> On Wed, Feb 18, 2009 at 07:32:19PM +0100, Kay Sievers wrote:
>> On Wed, Feb 18, 2009 at 18:51, Grant Likely <grant.likely@...retlab.ca> wrote:
>> > Mostly because I have no need another full struct device, and none of
>> > the files that I'm adding have any bearing on udev.  They are debug
>> > and statistical files for an embedded system that are used by the
>> > developer.  I don't want application code depending on them and I'm
>> > not interested in having them advertised.
>>
>> That's what debugfs is for.
>
> Kay is right, use debugfs for stuff like this.  Not sysfs.
>
> So sorry, I'm not going to apply the patch, and you should change your
> code to not open-code this as well.

Forgive my frustration, but I've been happily using sysfs for simple
exports of driver data (not just debug either; for tuning also) for a
while now with no indication that I've doing the wrong thing.  I
haven't found anything in Documentation or in LDDv3 that says files
should not be created at probe time.  The sysfs API is beautiful to
work with and requires less code than the equivalent debugfs
interface.  Often using it exactly matches the use case that I need;
small values, simple settings and safe, concise code.

So, I re-ask my questions:
When is it legal and when is it not legal to call
device_create_file()?  If debug only stuff belongs in debugfs, then
fair enough.  But what about when tuning controls are needed?  If I
have to create a child 'struct device', then I will do so, but I'm
still not convinced on the benefit.

Even then, I'm confused.  The KOBJ_ADD uevent is raised at
device_register() time.  However, it appear that device_create_file()
often gets called after device_register() (pci_bus_add_child() for
example).  What is the cutoff point for calling device_create_file()
so that attributes exist before the uevent (as Kay stated earlier in
this thread)?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
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/