linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPXgP10__1iCP8yCbfg7fJpK85_7C=P2MdP78b-1UwmOOt4OFA@mail.gmail.com>
Date:	Sun, 4 Mar 2012 19:59:23 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Federico Vaga <federico.vaga@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alessandro Rubini <rubini@...dd.com>,
	linux-kernel@...r.kernel.org
Subject: Re: How to make a bus with heterogeneous devices?

On Sat, Mar 3, 2012 at 16:44, Federico Vaga <federico.vaga@...il.com> wrote:
>> Maybe I miss something but it sounds not that different from USB.
>>
>> You have a bus that enumerates devices and a "bus driver" creates a
>> generic device on that bus for everything it finds. These devices stay
>> generic, do not have type-specific attributes, but export matches
>> again to bind other device-specific drivers, which create _new_ child
>> devices below the generic ones with the proper attributes matching
>> their individual type of devices. So every "logical" device is always
>> represented by one generic device and one type-specific child device.

>> 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.
>
> - I register the generic (empty) device on the bus

You can always add some generic, no-type specific attributes there, if
that fits in your model.

> - when the device match with a driver
>  - I register a new device child of the matched one but without connect
>    it directly on the bus.

You can assign all these devices to the same bus (see details below).

> The result will be something like (zio is our bus):
>
> /sys/bus/zio/devices/<generic-dev1>/<real-device1>/<attributes>
> /sys/bus/zio/devices/<generic-dev2>/<real-device2>/<attributes>
> /sys/bus/zio/devices/<generic-devN>/<real-deviceN>/<attributes>
>
> When there is not a driver:
>
> /sys/bus/zio/devices/<generic-dev1>/<device-stuff>
> /sys/bus/zio/devices/<generic-devN>/<device-stuff>
>
> Where the generic-dev is an empty device used to make the bus work. Is
> it correct?

All buses have have a 'subsystem directory' at:
  /sys/bus/
This location exposes the 'device tree classification', like the
'collection of devices by subsystem'

The bus "zio" has its directory at:
  /sys/bus/zio/

All devices known to the bus "zio" are referenced at:
  /sys/bus/zio/devices/*

Which is a bunch of symlinks pointing into the:
  /sys/devices/
directory, which is the tree of all devices from all subsystems. This
tree exposes the 'device tree hierarchy'.

So your registered devices would all show up in:
  /sys/bus/zio/devices/generic0 --> ../../../devices/.../generic0
  /sys/bus/zio/devices/generic1 --> ../../../devices/.../generic1
 /sys/bus/zio/devices/generic2 --> ../../../devices/.../generic2
  /sys/bus/zio/devices/type-a0 --> ../../../devices/.../generic0/type-a0
  /sys/bus/zio/devices/type-a1 --> ../../../devices/.../generic1/type-a1
  /sys/bus/zio/devices/type-b0 --> ../../../devices/.../generic2/type-b0

They all show up on the same bus, but the type-specific devices are
child devices of the generic ones.

>> All these devices, the generic ones and the type-specific ones can be
>> on the same bus (struct bus_type) when they get a "struct device_type"
>> assigned which carries the device-type specific set of attributes.
>
> But if all devices can live on the bus (set device->bus for all
> devices), when I register the "real-device" (type-specific)  the bus try
> to match it with a driver (again); but we already matched the device
> with its driver. it is better if the type-specific devices are not
> directly on the bus but only a child of a device on the bus.

You can sort them out by 'struct device_type' in your probe functions,
that should  not be a problem.

We generally do not like devices which do not belong to a bus or
class, they are kind of 'invisible' to userspace, and udev can not use
them directly, it sees them only as a parent device of a device with a
bus or class.

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/