From owner-freebsd-arch@freebsd.org Tue Jun 7 19:50:58 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 532D3B6D64C for ; Tue, 7 Jun 2016 19:50:58 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D798F111A; Tue, 7 Jun 2016 19:50:57 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id s64so122230517lfe.0; Tue, 07 Jun 2016 12:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bEEz7XNbOPYHC8MQr/WPHK4yDlQBvlkJtQnCVOrrQCU=; b=KseFBvjk69bokuhS93/aDUWbAgiC6vkZvVDJGp7R9wRfuVAVtyqMuporyBfxZf/5r7 i1T7XylAomhNvw3URQvgNjw+4sz1KySYME/8aXBimr2M/CJAC50rA7R/pRaiitVkweRJ TQKMDftK53z5akVx0h8i+LJ57UKOOYPtEg5BGViUMr4H1ICfzGEETueU6PTBm1845x3P va39pDhSBfRdrgDNxnIrvySIKYH09BfioXCs1ibNsW+Yqs8+wFdeZEtlMEvNDm4ofaPQ Yi8Kb/OpZzk4C5WV2/mHcTzS3QumTOruf1PX23+ks+9+qOhudM75C51JO2FOwZxAJjBS Taxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bEEz7XNbOPYHC8MQr/WPHK4yDlQBvlkJtQnCVOrrQCU=; b=CybZ7NrKU91n12C/xsURqjf/cOykmq91WVtweTWV0WxQpRputOcCdJjPF78/JZ2cae LFWCIL0aNv4zvM4EjiCnfAX8yaN7qHXb7Ds9kq2JUz/7JX3sNwFtD+olORtkmUEBZ/WN 0ok2tE/CREObnZ1cDIXqu3sfqT14oeuvtBIJhT4B+jy0FaF3rjGuG9nH3hAb2GrP8uSv YfR55AvzWiC1lu+25cytO1qLIPMxORHuzRL6e8d6kM+9rHMGPNI5RIGv/PvqjpVDDQIv 0XCN3TNq/AJ+RYxoFYgejvpeC56yp9Ud8oAGVPnjlQNBYkiuwjNzHEEnCxTbgI3QI4tT jzFA== X-Gm-Message-State: ALyK8tIPshfbhL3czjG2GFMQXgQbizJhrGNQisECZaGRXe7WrrpgR7ux2VGFi6bc414nxvHH9oyjhu3zeLPDCQ== X-Received: by 10.46.9.11 with SMTP id 11mr299462ljj.5.1465329055904; Tue, 07 Jun 2016 12:50:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.16.166 with HTTP; Tue, 7 Jun 2016 12:50:55 -0700 (PDT) In-Reply-To: <1465241688.1188.18.camel@freebsd.org> References: <13621.1465030369@critter.freebsd.dk> <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> <1465241688.1188.18.camel@freebsd.org> From: KILOREUX Emperex Date: Tue, 7 Jun 2016 20:50:55 +0100 Message-ID: Subject: Re: API to link sysctl nodes to devices To: Ian Lepore Cc: Warner Losh , Koop Mast , Poul-Henning Kamp , eadler@freebsd.org, =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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: Tue, 07 Jun 2016 19:50:58 -0000 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 wrote: > 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=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.. 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" > > >