Hi Lennart,

Thanks for your reply, and notice to this legacy and minor issue ;)

On Mon, Jun 17, 2019, at 22:26, Lennart Poettering wrote:

On Mo, 20.05.19 21:27, Takashi Sakamoto (o-takashi@sakamocchi.jp) wrote:

...

Hi all,

I'm an ALSA developer, mainly committing to drivers for audio and music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a concern about access permission for fw character device.

I am not sure I understand firewire well enough to say something too smart. But if I understand correctly, then we (in systemd upstream) currently only have these four firewire specific rules in our tree:

SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video" SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video" SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video" SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video"

And all of these are handled by some firewire core driver?

Although it's probable that some of them are handled by in-kernel driver (perhaps firedtv.ko), they're just for userspace applications. The in-kernel driver adds another device to system (in this case video character device) and access rules to it are apart from the one for fw character device, as long as all features are implemented in the in-kernel driver.

In a case of drivers in ALSA firewire stack, we decided to implement a part of features in userspace application, due to the complexity of vendor-dependent protocols. The in-kernel drivers just implement isochronous packet streaming for PCM frames and MIDI messages, and tells userspace applications the related fw character device via ALSA hwdep interface[1].

The devices you care about, how would the rules look like for this?

Here, I'd like to explain about the relationships between instances on IEEE 1394 bus topology and fw character device, modalias on in-kernel driver.

``` IEEE 1394 bus + node A (=fw character device, /dew/fw0) + unit A1 (=modalias on in-kernel driver, fw0.0) + unit B2 (=modalias on in-kernel driver, fw0.1) + ... + node B (=fw character device, /dev/fw1) + unit B1 (=modalias on in-kernel driver, fw1.0) + unit B2 (=modalias on in-kernel driver, fw1.1) + ... + ... ```

The relationship between node/unit is similar to device/interface in USB case. One node can includes several units which represent actual functionalities, and any in-kernel driver is bound to one of the units. On the other hand, fw character device is added for each node. The node is subject of communication.

When any driver in ALSA firewire stack is bound to one of units in a node, I expect udevd to change group of the corresponding fw character device to 'audio', and expect logind to assign ACL to it.

+ node A (fw character device with 'audio' group, +uaccess) + unit A1 (any driver in ALSA firewire stack is bound to)

In current framework of udev rule, this seems to be difficult to achieve, in my opinion. Thus, if I managed to achieve it by rule framework, I would add and maintain many entries generated from my registry[2].

In general, when it comes to auto-loading of drivers we usually expect the kernel to add modalias metadata to .ko files.

In the hwdb usually mostly only "auxiliary" data is stored, i.e. stuff that is great to have but is not essential for a device to work basically.

Rules files should generally be kept short. i.e. if you add 3 more rules for the devices you care about, that'd be fine — if you add 100, then that's not so great however, and another approach should be found.

Yes. I'd like to avoid increasing maintenance cost of anybody including myself...

Anyway, given that I am not a firewire pro, I figure you have to decide yourself what the best approach is, and then prep a PR and we can have a look. Without looking at an (maybe just RFC) patch I am not sure I grok enugh to properly comment on it.

Okay. I'll attempt to post several RFC patches. It takes me a bit long time because this is my first attempt to commit systemd, but I'm happy if you review and comment to them.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/incl... [2] https://github.com/takaswie/am-config-roms

Thanks

Takashi Sakamoto