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:	Fri, 02 Mar 2012 11:18:59 +0100
From:	Federico Vaga <federico.vaga@...il.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Alessandro Rubini <rubini@...dd.com>, linux-kernel@...r.kernel.org
Subject: Re: How to make a bus with heterogeneous devices?

> That's fine, it is what happens with lots of drivers, you can do this
> with the default attribute group assigned to that driver, right?

We can't because a driver can handle devices with different set of 
attributes. We  can't use device->groups because only if match succeed 
we know which attributes add to the device.
That's because the same driver handles several similar devices, to avoid 
proliferation of almost-identical drivers. So the drivers attaches 
attributes to the device after match succeeds.

The solution that I temporarily  implemented is the following:

> > [...]
> > 3- Attributes may be added after match succeeds, before calling
> > probe.
> > This cam be done with a "raw" call to sysfs_create_group(); then
> > groups cna be added to dev->groups so they will be removed on
> > device_unregister().
> > [...]

(with calling probe I mean calling "my" driver probe)

I know it's not a nice solution and I know it's not nice add groups to 
device->groups after registration. I can use sysfs_create_group() and 
sysfs_remove_group() without touching the device.
 
> I think you need to look at how the system bus is handled.  It just 
> went into 3.3-rc and allows for "different" types of devices to all be 
> on the same bus, with different drivers and attributes.  Let me know if 
> how that works does not work out for you.

(thank you for the reference to the patches)

I think it doesn't work in our case for the same reason we can't use 
device_driver->groups: we know too late in the register process which 
attributes add to a device, practically at the end of the registration.
Maybe I'm missing something.

-- 
Federico Vaga
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ