Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Feb 2015 15:38:01 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        bugzilla-noreply@freebsd.org
Cc:        freebsd-usb@FreeBSD.org
Subject:   Re: [Bug 198015] devd(8) overwrites "bus" on ugen event
Message-ID:  <1424817481.1328.9.camel@freebsd.org>
In-Reply-To: <bug-198015-17@https.bugs.freebsd.org/bugzilla/>
References:  <bug-198015-17@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-02-24 at 21:47 +0000, bugzilla-noreply@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198015
> 
>             Bug ID: 198015
>            Summary: devd(8) overwrites "bus" on ugen event
>            Product: Base System
>            Version: 10.1-RELEASE
>           Hardware: Any
>                 OS: Any
>             Status: New
>           Severity: Affects Only Me
>           Priority: ---
>          Component: usb
>           Assignee: freebsd-usb@FreeBSD.org
>           Reporter: johan@stromnet.se
> 
> Problem:
> When trying to match a uftdi device arrival, "bus" variable is overwritten.
> This means I cannot know which /dev/ugenN.N node to work with (which in my case
> is chown to a specific user).
> 
> Example: (FreeBSD 10.1, devd in console mode):
> 
> Sample devd script:
>    attach 10 {
>       device-name "uftdi[0-9]+";
>       action "chgrp dialer /dev/ugen$bus.$devaddr; chmod 660
> /dev/ugen$bus.$devaddr"
>    };
> 
> Processing event '+uftdi0 at bus=0 hubaddr=1 port=3 devaddr=2 interface=0
> vendor=0x1781 product=0x0c30 devclass=0x00 devsubclass=0x00 sernum="XXXXXX"
> release=0x0600 mode=host intclass=0xff intsubclass=0xff intprotocol=0xff 
> ttyname=U0 ttyports=1 on uhub1'
> Pushing table
> setting device-name=uftdi0
> setting bus=0
> setting hubaddr=1
> setting port=3
> setting devaddr=2
> setting interface=0
> setting vendor=0x1781
> setting product=0x0c30
> setting devclass=0x00
> setting devsubclass=0x00
> setting sernum=A6008W8a
> setting release=0x0600
> setting mode=host
> setting intclass=0xff
> setting intsubclass=0xff
> setting intprotocol=0xff
> setting ttyname=U0
> setting ttyports=1
> setting bus=uhub1
> Processing attach event
> Testing device-name=uftdi0 against ^ed50$, invert=0
> Testing device-name=uftdi0 against ^ubt[0-9]+$, invert=0
> Testing device-name=uftdi0 against ^ukbd0$, invert=0
> Testing vendor=0x1781 against ^0x0854$, invert=0
> Testing vendor=0x1781 against ^0x1645$, invert=0
> Testing device-name=uftdi0 against ^uftdi[0-9]+$, invert=0
> Testing vendor=0x1781 against ^0x0403$, invert=0
> Testing device-name=uftdi0 against ^uftdi[0-9]+$, invert=0
> Testing vendor=0x1781 against ^0x1781$, invert=0
> Testing product=0x0c30 against ^0x0c30$, invert=0
> Executing 'chgrp dialer /dev/ugenuhub1.2; chmod 660 /dev/ugenuhub1.2'
> chgrp: /dev/ugenuhub1.2: No such file or directory
> chmod: /dev/ugenuhub1.2: No such file or directory
> Popping table
> 
> 
> My suspect:
> https://github.com/freebsd/freebsd/blob/master/sbin/devd/devd.cc#L821
> 
> 
> 
> Is there any other way to reliably get the corresponding ugen device?
> 

This is pretty yucky to fix.

My first thought was that the pnpinfo should contain usbus= rather than
bus=, but I checked, and making that change will break our software at
$work (and thus presumably other 3rd party software that directly reads
devd.pipe and relies on the current format of usb pnpinfo too).

Another possibility would be to add usbus= to pnpinfo and also leave
bus= there for compatibility with out-of-tree software.

Yet another possibility would be to add a ugen=n.n to pnpinfo.  I
especially like this idea.

-- Ian





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1424817481.1328.9.camel>