[systemd-devel] 70-uaccess.rules: add new ID_SDR_HW?

Kay Sievers kay at vrfy.org
Mon Jul 14 17:03:00 PDT 2014


On Tue, Jul 15, 2014 at 1:50 AM, Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
> On Mon, Jul 14, 2014 at 07:40:10PM +0800, Alick Zhao wrote:
>> Hi all,
>>
>> I am recently playing with software
>> defined radio (SDR) hardwares (USRP, bladeRF, etc.),
>> and come across the plugdev group issue. It seems the best way is to
>> write a local rule
>> saying something like: [1]
>>
>>   SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \
>>     ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy" \
>>     ENV{ID_<some_name>}="zzzz"
>>
>> and to rely 70-uaccess.rules [2] to grant the permission.
> For logind to grant permissions, *something* has to set the uaccess tag.
> This can be done in 70-uaccess.rules, but it could also be done
> in rules delivered by a different project.

So far, we reserved the right to change the tag, and did that at least
two times in the past already.

>> However, it seems there is no proper ID for SDR hardware for the
>> moment, so I have to
>> write TAG+="uaccess" directly in local rule file. AFAIK it is not recommended.
> I don't see why that should be bad.

The admin should be able to enable/disable specific classes, using the
tag directly is not recommended.

>> So is it possible to add ID_SDR_HW in the 70-uaccess.rules file?
> It could be done. Whether systemd is the best place to keep the rules
> for SDR depends on whether there's a better project, like sane for scanners,
> etc.
>
>> You may suggest a better name of course.
> Something longer would be better.

Right, we try to avoid abbreviations which do not explain themselves.

>> Besides, I see there are inconsistency of ENV{ID_<some_name>} in [2]
>> ("*?" vs "?*").
>> Do they match different things? Hope you can clarify.
> They are equivalent and both match a string with a least one character.

"?*" is preferred and optimized-out by the udev rules logic. I'll go
and switch them over.

Kay


More information about the systemd-devel mailing list