API to link sysctl nodes to devices

[KILOREUX Emperex]

cdev as root oid for linking makes a lot of sense yeah, and since the ucom
is handling it for usb serial adapters , I am not sure how a new API could
improve or harm this, since the task description imposes on a specifically
generic API, I would love to hear more about your specific thoughts for how
it should be approached since my mentor is busy :( .

On Mon, Jun 6, 2016 at 8:34 PM, Ian Lepore <ian at freebsd.org> wrote:

> 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"
> >
>