From owner-freebsd-arch@freebsd.org Mon Jun 6 19:34:57 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8FF3B6DE38 for ; Mon, 6 Jun 2016 19:34:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CE761B7D for ; Mon, 6 Jun 2016 19:34:57 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c35d451a-2c1d-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 6 Jun 2016 19:35:02 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u56JYm8V006675; Mon, 6 Jun 2016 13:34:48 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1465241688.1188.18.camel@freebsd.org> Subject: Re: API to link sysctl nodes to devices From: Ian Lepore To: Warner Losh , KILOREUX Emperex Cc: Koop Mast , Poul-Henning Kamp , eadler@freebsd.org, =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , freebsd-arch@freebsd.org Date: Mon, 06 Jun 2016 13:34:48 -0600 In-Reply-To: <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> References: <13621.1465030369@critter.freebsd.dk> <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:34:57 -0000 On Sun, 2016-06-05 at 23:53 -0400, Warner Losh wrote: > > On Jun 5, 2016, at 11:07 PM, KILOREUX Emperex > > 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.. 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" >