Date: Mon, 06 Jun 2016 13:34:48 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <wlosh@bsdimp.com>, KILOREUX Emperex <kiloreux@gmail.com> Cc: Koop Mast <kwm@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, eadler@freebsd.org, =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= <dumbbell@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: API to link sysctl nodes to devices Message-ID: <1465241688.1188.18.camel@freebsd.org> In-Reply-To: <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> References: <CAN1JrQ2dd0WZi0_aaNdqH9xdy292tP2DYLxvKV9bfK93vYFLXw@mail.gmail.com> <13621.1465030369@critter.freebsd.dk> <CAN1JrQ1eSr3%2BrPuF5d6USX=V_cTjzuAG=VXd7pFphO%2BEk2gE%2BQ@mail.gmail.com> <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2016-06-05 at 23:53 -0400, Warner Losh wrote:
> > On Jun 5, 2016, at 11:07 PM, KILOREUX Emperex <kiloreux@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@phk.freebsd.dk>
> > wrote:
> >
> > > --------
> > > In message <
> > > CAN1JrQ2dd0WZi0_aaNdqH9xdy292tP2DYLxvKV9bfK93vYFLXw@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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "
> freebsd-arch-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1465241688.1188.18.camel>