On Oct 27 Takashi Sakamoto wrote: > On Oct 20 2015 16:39, Stefan Richter wrote: > > The console owner policy and ACL mechanism are not a complete replacement > > for the group mechanism though: > > - There may be headless systems and other occasions at which the audio > > user is not console owner. > > I think usual user doesn't use such systems. Here, I imagine the user > works with major Linux discribution such as Ubuntu. > > > - Processes involved in capture or playback, i.e. applications beyond > > mixers, may require realtime scheduling class privilege and memlocking > > privilege, which are traditionally configured for Unix groups and > > users (typically for a group). Not sure whether a mechanism exists > > which can implement a console owner policy for realtime and memlock > > privileges. > > Hm. About such applications which changes scheduling attributes of > tasks, the user intentionally run for his or her purpose. I think this > is not so usual cases which the system should support as a default. I mentioned the two points mostly as an illustration for pros and cons of Unix groups mechanism/ policy in comparison to ACL mechanism/ console owner policy. If one of us submits new rules for inclusion into mainline systemd git, I assume that the udev rules maintainers of the systemd project will direct us as necessary, so that good default mechanisms and policies are implemented. [...] > There's another issue. In this time, I also added TASCAM FireOne support > to ALSA OXFW driver. Any login users are granted to access the > corresponding character device, while the device node belongs to 'video' > user. I think this line causes this issue: > https://github.com/systemd/systemd/blob/c379f143a5ccdbc94a87cfca0174e7f21fa05f26/rules/50-udev-default.rules#L43 > > The model has 0x00a02d for 'specifier_id' in its unit directory of > CONFIG ROM. This may match the line. In earlier times, some or all of these lines had comments that explained what is what. The comments were removed eventually. Here is what each Specifier and Version (i.e. protocol) identifiers means (see also bottom of http://1394ta.org/1394-test-resources/): SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video" specifier: 1394 TA protocol: IIDC (Instrumentation & Industrial Digital Camera) SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video" specifier: Point Grey Research, Inc. protocol: IIDC (actually plain IIDC as specified by 1394 TA, but AFAIK the nonstandard specifier ID is there to get the vendor's driver loaded on other OSs) SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video" specifier: 1394 TA protocol: AV/C SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video" specifier: 1394 TA protocol: AV/C and vendor-unique Note, the "*" asterisks in these patterns serve two purposes: First, a node with several units will expose a space-separated list of specifier:version tuples in the units attribute. Second, the version ID is always 24 bits wide, but we may want to match just the uppermost 20 or fewer bits of the version. BTW, the "units" attribute and the others are described in Documentation/ABI/stable/sysfs-bus-firewire. But here is an example from a device with four units: $ cat /sys/bus/firewire/devices/fw13/*{name,units} iSight Apple Computer, Inc. 0x00a02d:0x000102 0x000a27:0x000010 0x000a27:0x000011 0x000a27:0x000012 (IIDC v1.30, iSight audio, iSight factory, iSight iris units) As you know, firewire-core merely discovers nodes and units (including AV/C units), but not subdevices below them, such as SBP logical units or AV/C subunits. Consequently, firewire-core does not expose a sysfs attribute which describes the AV/C subunit type (monitor, audio, disc, tape, tuner, camera, music, and more). The first udev rules for FireWire devices were written in times when camcorders and other DV devices were considered more numerous in use than audio AV/C devices. Hence the choice of GROUP="video" which has been carried over from that time. In addition, many distributions at the time added new user accounts to a "video" group by default, but fewer distributions did the same with an "audio" group. Do we need to add AV/C subunit discovery to firewire-core, in order to add AV/C subunit type attributes to sysfs? Perhaps not, if we can come up with udev rules for audio devices which work off existing attributes like those which the audio kernel drivers themselves match by their mod-alias. We need to restrict ourselves to "node device attributes" in /sys/bus/firewire/devices/fw[0-9]+/ though. The "unit device attributes" in /sys/bus/firewire/devices/fw[0-9]+[.][0-9]+/ cannot be used because they are populated in later uevents than the one which triggers creation of the /dev/fw* file. -- Stefan Richter -=====-===== =-=- ==-== http://arcgraph.de/sr/ _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
