API to link sysctl nodes to devices

[Ian Lepore]

On Sun, 2016-06-05 at 23:53 -0400, Warner Losh wrote:
> > On Jun 5, 2016, at 11:07 PM, KILOREUX Emperex <kiloreux at gmail.com>
> > wrote:
> > 
> > Hey,
> > 
> > Thanks for your feedback, but we have been over this and what you
> > are
> > proposing seems pretty interesting, can you please elaborate on how
> > that
> > could be implemented inside the kernel, or give more details about
> > it, also
> > it seems a bit cool if we could do both of them together, so what
> > do you
> > think about sysctl nodes, is there any disadvantages for the
> > implementation
> > of such API ?
> > 
> > On Sat, Jun 4, 2016 at 9:52 AM, Poul-Henning Kamp <
> > phk at phk.freebsd.dk>
> > wrote:
> > 
> > > --------
> > > In message <
> > > CAN1JrQ2dd0WZi0_aaNdqH9xdy292tP2DYLxvKV9bfK93vYFLXw at mail.gmail.co
> > > m>
> > > , KILOREUX Emperex writes:
> > > 
> > > > As part of my participation GSOC, I have been working on an API
> > > > spec to
> > > > link sysctl nodes to devices.
> > > 
> > > It's not really the sysctl nodes as such you should focus on, but
> > > rather on the gap between (the increasingly inaccurately named)
> > > newbus and devfs.
> > > 
> > > The poster-boy example is how you get from USB bus coordinates to
> > > /dev/da* or /dev/{tty|cua}U* devices.
> > > 
> > > devd(8) seems to know the linkage and usually I resort to
> > > /etc/devd
> > > entries like this to make it liveable:
> > > 
> > >        attach 1000 {
> > >                match "device-name"     "uftdi[0-9]*";
> > >                match "vendor"          "0x0403";
> > >                match "product"         "0x6001";
> > >                match "sernum"          "FTHAV9UU";
> > >                action "ln -s /dev/cua$ttyname /dev/bbb1";
> > >        };
> > > 
> > >        notify 1000 {
> > >                match "system"          "USB";
> > >                match "subsystem"       "DEVICE";
> > >                match "type"            "DETACH";
> > >                match "vendor"          "0x0403";
> > >                match "product"         "0x6001";
> > >                match "sernum"          "FTHAV9UU";
> > >                action "rm -f /dev/bbb1";
> > >        };
> 
> For /dev/da* we created a geom creation event that should be used 
> instead of a USB insertion event, which removed the strain we had. 
> For uftdi vs ttyUx thing, though, there’s a problem. We could do a 
> device creation event as well (there may already be one), but there’s 
> no way to connect the /dev/ttyUx back to the newbus device_t node, 
> which can be used look up info about the device to do interesting 
> things with. One way to do this would be dev.uftdi.0.%devnodes: ttyU2 
> ttyU3, which would require some new APIs for adding a dev_t to a 
> device_t. But that might be backwards. I’d like something more like 
> devnode.ttyU2.device: uftdi0 would do the trick (or uftdi.0, since 
> device names can have numbers in them, which is why the sysctl nodes 
> under dev are the way they are). Note ‘devnode’ is just a name, I’m 
> agnostic, but given that dev is already taken (and its an API for 
> many device drivers, so changing it would be difficult) ‘devnode’ 
> seems the next best thing, but I’m open to other names.

We already have all the info you need to get from dev.uftdi.* to the
corresponding /dev/{tty,cua}U# nodes using the ttyname field in the
pnpinfo:

    dev.uftdi.0.%pnpinfo: vendor=0x9e88 product=0x9e8f devclass=0x00
    devsubclass=0x00 sernum="FTVB685F" release=0x0500 mode=host
    intclass=0xff intsubclass=0xff intprotocol=0xff ttyname=U0
    ttyports=1

I think it's handled by the ucom (usb_serial) layer so it's the same
for all usb serial adapters.  But a similar facility is probably
missing for any other type/class of device.

Also, afaik, there is no easy way to get from /dev/cuaU# to the
corresponding dev.<drivername>.<unit> collection of sysctl info, other
than by iterating the entire dev.* oid hierarchy looking for it.

How about cdev.* as the new top-level oid you propose for linking
character device entries to their related driver oids?

-- Ian

> Of course, having a stronger coupling between device_t and dev_t
> would allow us to detect when /dev/foo isn’t destroyed when the
> device_t created it gets detached.
> 
> As for sysctl, there’s already a sysctl tree that’s tightly coupled
> to a device instance that any device can take advantage of. I’m not
> sure what you need here, unless it’s what I described in the last
> paragraph.
> 
> Warner
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "
> freebsd-arch-unsubscribe at freebsd.org"
>