Prevent attach of modem serial emulated device on USB attach?

[Karl Denninger]

On 4/30/2016 09:15, Hans Petter Selasky wrote:
> On 04/30/16 16:06, Karl Denninger wrote:
>> So I have managed to get access via ugen to one of the USB devices I
>> want to talk to.
>>
>> I would like to generalize that in a library, but am confounded by a
>> /second /device that comes up "looking like a modem", although it is
>> not.  This is convenient if you want to open and deal with it like a
>> modem, but unfortunately that attachment appears to prevent me from
>> successfully using it with the ugen interface at the same time, as the
>> attachment looks like it "eats" the inbound byte stream.
>>
>> Is there a reasonably-easy way to /prevent /FreeBSD from declaring this
>> device eligible to be attached as if it was a character-style modem,
>> leaving it only on ugen?  I have figured out how to use devd to change
>> permissions on attach, but not how to prevent it from attaching a
>> generic USB device to a specific driver.
>>
>
> Hi,
>
> Did you try:
>
> libusb_detach_kernel_driver() or
>
> libusb20_dev_detach_kernel_driver()
>
> --HPS

I can probably code that into the application but what I'm looking for
is something that can be stuck into devd's config (or similar) that will
prevent the attachment in the first place when the device is plugged in.

The issue is that I have multiple "things" that I want to talk to in
this application at the same time, multiplexing them via threads and
select().  One of them is only a serial driven thing, and thus I have to
live with the reality of a USB serial dongle for those machines that
don't have a built-in serial port.  Ideally, I'd like to talk to
everything that can come up on USB native via the ugen interface, which
(for my purposes) is quite good since I don't mind having a second file
handle open for write and, what's better, is that since I can open the
control instance without blowing things up if someone else has the
device open for some purpose I can make very sure I have the right
device with the vendor and product Ids before I start trying to talk to it.

Unfortunately if it's a serial port all I can do is try to probe it, and
hope that my off-baud (if I get it wrong) inquiry strings don't cause
the device to go insane since (and here's the really bad news) the
serial-only one doesn't honor modem control lines as a means of insuring
a hard reset.  Unfortunately since serial USB interfaces have no
consistent order, especially if plugged in after boot, I can't hard-code
a config file entry either.

If I can prevent this other device from attaching in the first place to
a modem port via umodem then at application start I can iterate over the
/dev/usb/x.y.0 nodes and, when I find the rights ones, open them up. 
This leaves me only one possibility in the supported interfaces for a
device that appears as a serial interface which will greatly reduce the
risk of making that particular device insane.

While I can "detach" at program start this doesn't help me with a
hot-plug possibility; if I can't prevent the attachment in the first
place then I may as well live with the risk of fraggling the "wrong"
serial device since if someone plugs or unplugs while it's running I
have to accept that risk anyway.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-usb/attachments/20160430/29637d64/attachment.bin>