linux-kernel - How to make a bus with heterogeneous devices?

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-next>] [day] [month] [year] [list]

Message-ID: <20120224152051.GA23232@mail.gnudd.com>
Date:	Fri, 24 Feb 2012 16:20:51 +0100
From:	Alessandro Rubini <rubini@...dd.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	federico.vaga@...il.com, linux-kernel@...r.kernel.org
Subject: How to make a bus with heterogeneous devices?

Hello Greg. 

Federico Vaga and me are working on the ZIO framework
(ohwr.org/projects/zio) and he's currently adding the bus abstraction,
so we can support several cards of the same type.  Under ZIO,
different devices may have different attributes: an SPI ADC chip may
allow to choose from two voltage references while a PCI digital-output
device may have a device-wide clocking rate.

But the list of attributes associated to a device is only known when
the driver is matched. In other workds, the "device" part is only
claiming "here I am and I'm called <sth>", then the probe method of the
<sth> driver will instantiate the device with its attributes.

However, the device appears in sysfs whether or not there is a driver
for it (which we agree is correct), but the list of attributes is only
known when the driver is matched -- because the list is known to the
driver, not to the device.

Here are some paths we evaluated:

1- /sys/bus/zio/devices may include place-holders, while a successful
match and probe will create real stuff is in /sys/zio/devices/<sth>-0/
But this would mean kobjects and you mandated us to only use devices
instead.

2- Like above, but falling in /sys/devices/virtual/zio/ ?

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().

4- Attributes may be added to the device before drv->probe is called
(or after it succeeds), using FIXMEFEDE. But .... FIXMEFEDE

5- The real attributes may live in another device, which is a child of
the one used within the bus abstraction.  Here the drawback is using
an additional device and directory level for no reason.

6- We may use a fake (almost empty) device for the match function, and
then register the real one, with full attributes, when the match
succeeds (so match is called again and must be worked around). This
would work but is clearly a horrible hack.

We looked at other bus abstractions, and all of them host homogeneous
devices (they may have sub-devices, but none of them has different
attributes).  Even the platform bus has no per-device attribute list
instantiated by the driver.  In the cases where the attribute list is
different for each device, the list is known to the device, before the
match function is called.

Any suggestion is welcome. Meanwhile, Federico started implementing 3
above, but it still looks a dirty approach, and possibly not future-proof.

thanks
/alessandro (and federico)
--
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/