Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jul 2020 23:18:51 +0000
From:      "Brian Mcgovern (bmcgover)" <bmcgover@cisco.com>
To:        Ian Lepore <ian@freebsd.org>, Hans Petter Selasky <hps@selasky.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Question on structure of USB (specifically USB Serial) stack
Message-ID:  <BL0PR11MB344286D12DDD48451E274141C57F0@BL0PR11MB3442.namprd11.prod.outlook.com>
In-Reply-To: <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org>
References:  <BL0PR11MB34425EBBCF3E674E6A7766E1C57F0@BL0PR11MB3442.namprd11.prod.outlook.com> <c20edccb-616b-aedf-6a60-e4857341f2fb@selasky.org>, <82c1e5cede57ced764bfc3a33c75cc0b36a67660.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Ian Lepore said:

This seems to me to be one of those situations where answering the
exact question that was asked isn't the right thing to do.  Instead it
needs to be answered with another question:  What it is you're really
trying to accomplish, and why do you think doing this crazy-unsafe
casting is the only way to get it done?

I get its crazy unsafe for the non-specific case. That is why I'm asking th=
e question - to see if there is a good way to get the info.

What I'm hoping to do is pin some USB devices with FTDI interfaces to more =
consistent name, similar to /dev/usb, based on the tree of struct usb_devic=
e entries and their respective addresses. What I see with the cuaUXX format=
ting is that if one gets rebooted or someone hits the power cord, it'll bou=
nce fast enough that it'll come back with a different name. As a result, ev=
en though we can get a consistent layout on power up, if you come back a we=
ek or two later, everything is out of order. I was hoping that if I could a=
t least get an alias that mapped to the port the device was in, that would =
be sufficient to find the "right one", regardless of what the cuaUX names w=
ere doing.

The reason for picking this particular section of the code is that it appea=
rs I can get most of the work done locally and have similar behavior with a=
ll of the devices that share ucom. However, if what I'm seeing as a hurdle =
is really a wall, I'm open to better ideas.

   -B
________________________________
From: Ian Lepore <ian@freebsd.org>
Sent: Thursday, July 16, 2020 6:32 PM
To: Hans Petter Selasky <hps@selasky.org>; Brian Mcgovern (bmcgover) <bmcgo=
ver@cisco.com>; freebsd-hackers@freebsd.org <freebsd-hackers@freebsd.org>
Subject: Re: Question on structure of USB (specifically USB Serial) stack

On Thu, 2020-07-16 at 23:21 +0200, Hans Petter Selasky wrote:
> On 2020-07-16 22:20, Brian Mcgovern (bmcgover) via freebsd-hackers
> wrote:
> > All,
> >    I'm doing some playing with the ucom code, and I'm down to a
> > link in the data that I'm just not confident I've parsed the code
> > correctly. In sys/dev/usb/serial/usb_serial.c,  specifically in
> > ucom_attach_tty, I'm trying to get a reference to the usb_device
> > structure for the device used elsewhere in the USB code. The
> > specific devices I'm working with are USB->RJ 45 cables with a
> > built in FTDI chip, in case this matters
> >
> >    It appears that the ucom_super_softc and ucom_softc structures
> > are available. From looking around the code, it appears the
> > sc_parent field of ucom_softc is pointing back to the uftdi_softc
> > structure in uftdi.c (for the uftdi case), so the path would be
> > ucom_softc->sc_parent->sc_udev, but my concern is going through the
> > void *, as it appears each of the devices that use ucom as the base
> > have sc_udev in a different part of their structure, meaning I'm
> > likely going to crash the system if I plan on it being an FTDI
> > device, and its not. Is there a callback or a canonical mechanism
> > for accessing this part of the structure given a starting point of
> > the ucom_softc? Alternatively, are there any well defined
> > attributes I can use to figure out what that void* is pointing to,
> > or at least conditionalizing the code so I can dereference it
> > correctly?
>
> Hi,
>
> Usually using void pointers this way works fine, as long as you are
> careful. There is also something called __containerof() which can be
> used to get the pointer to a structure based on the pointer to a
> structure inside that structure, thinking of the struct ucom_softc,
> which is type-safe.
>
>

You still can't just blindly cast ucom_softc->sc_parent back to a
struct uftdi_softc in ucom_tty_attach() because it will crash and burn
if any non-ftdi serial device is attached.  Using __container_of()
doesn't change that in any way -- you must already know for certain
that the type pointed to by the pointer is the type you name in the
container_of() invocation.

This seems to me to be one of those situations where answering the
exact question that was asked isn't the right thing to do.  Instead it
needs to be answered with another question:  What it is you're really
trying to accomplish, and why do you think doing this crazy-unsafe
casting is the only way to get it done?

-- Ian




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