Date: Tue, 7 Jun 2016 20:50:55 +0100 From: KILOREUX Emperex <kiloreux@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: Warner Losh <wlosh@bsdimp.com>, Koop Mast <kwm@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, eadler@freebsd.org, =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= <dumbbell@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: API to link sysctl nodes to devices Message-ID: <CAN1JrQ0inToLD3a2U1_vHzRCkRRo0DPzgePttL5106wQZa8kfw@mail.gmail.com> In-Reply-To: <1465241688.1188.18.camel@freebsd.org> 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> <1465241688.1188.18.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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=E2=80=99s a problem. We could d=
o a
> > device creation event as well (there may already be one), but there=E2=
=80=99s
> > 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=E2=80=99d 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 =E2=80=98devnode=E2=80=99 is just=
a name, I=E2=80=99m
> > agnostic, but given that dev is already taken (and its an API for
> > many device drivers, so changing it would be difficult) =E2=80=98devnod=
e=E2=80=99
> > seems the next best thing, but I=E2=80=99m 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=3D0x9e88 product=3D0x9e8f devclass=3D0x0=
0
> devsubclass=3D0x00 sernum=3D"FTVB685F" release=3D0x0500 mode=3Dhost
> intclass=3D0xff intsubclass=3D0xff intprotocol=3D0xff ttyname=3DU0
> ttyports=3D1
>
> 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=E2=80=99t destroyed when the
> > device_t created it gets detached.
> >
> > As for sysctl, there=E2=80=99s already a sysctl tree that=E2=80=99s tig=
htly coupled
> > to a device instance that any device can take advantage of. I=E2=80=99m=
not
> > sure what you need here, unless it=E2=80=99s what I described in the la=
st
> > 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?CAN1JrQ0inToLD3a2U1_vHzRCkRRo0DPzgePttL5106wQZa8kfw>