From owner-freebsd-arch@freebsd.org Mon Jun 6 03:53: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 14799B6B30C for ; Mon, 6 Jun 2016 03:53:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 D9352103F for ; Mon, 6 Jun 2016 03:53:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id f67so32963561ith.1 for ; Sun, 05 Jun 2016 20:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G69/gS/VtLFu0E5aAQowhtaKNIyWVA1RaMgk1LWko9s=; b=Gepi+tEOCk3lhyAFS+k+1907HDudVip+EyRySLIC4x4YHCrOtQVYqKCq8nXvBdrTwn NPmEdQYTCCIik0HiEaMKNOc/KBehGO4feSSM8fG4dIJ5CFY7E3In7VRvsXaWWkZItsDV K5OBSW1fdAQLME68jsRxh815t9GEkU1yS/Mx033qi2mef7EmepKXQYfUx/jCQ46VfiFm u6UouHs8yT5J1eUfIwaSNlszlmqRI38FhV2ic1XxjQIr81hB5YaXtTdqkFGB6Gyn5gb4 A/c/wGh6JXno0jqnYCrkZX6YEneCDD9xro2F3O6XwDT33/zn6ST7AA0LR+bnsoMRRaex nN7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G69/gS/VtLFu0E5aAQowhtaKNIyWVA1RaMgk1LWko9s=; b=QTjfamQJ2w0Ly114M0YvwI3roaziy4ab4eGTg3Cq9I7pHVs9I1LywIp+2R1bpHCSQL OwabBnjf5sGpOdOQR3cWaZ+uWZgrSbLOIAH9du34WAjncwjbQ0MHLFIuxpnYSGvAhjRL TLI3VBFH3js84JBv0fKbRt8d33Tjm+e/K9AMTJnFGqPaM3UVE4/OO9cL9uTyVJ/fpgwN 1AMd/oBiQEOhgPlpC19IhKVOL3cxiyWJ0j+jeHfppgkkae9la671XdsibiLe//BXXkoJ mxs+Byz598+l6gH4CWzBXAsgK0vDlI3HO9HHp6c49524mYkcbhYUr0aJrEJkvSIX85qi YZHA== X-Gm-Message-State: ALyK8tI/bUb2w+DngegUF852qo1PG7S3Isrx48t5BsYEWIoFpY/OvS41qO1lrZktnjEWKg== X-Received: by 10.36.41.79 with SMTP id p76mr13823798itp.31.1465185237018; Sun, 05 Jun 2016 20:53:57 -0700 (PDT) Received: from [172.17.66.143] (69-165-177-132.dsl.teksavvy.com. [69.165.177.132]) by smtp.gmail.com with ESMTPSA id k15sm8330541iod.22.2016.06.05.20.53.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 Jun 2016 20:53:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: API to link sysctl nodes to devices From: Warner Losh In-Reply-To: Date: Sun, 5 Jun 2016 23:53:54 -0400 Cc: Poul-Henning Kamp , Koop Mast , eadler@freebsd.org, =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= , freebsd-arch@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> References: <13621.1465030369@critter.freebsd.dk> To: KILOREUX Emperex X-Mailer: Apple Mail (2.3124) 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 03:53:58 -0000 > On Jun 5, 2016, at 11:07 PM, KILOREUX Emperex = wrote: >=20 > Hey, >=20 > 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 ? >=20 > On Sat, Jun 4, 2016 at 9:52 AM, Poul-Henning Kamp > wrote: >=20 >> -------- >> In message < >> CAN1JrQ2dd0WZi0_aaNdqH9xdy292tP2DYLxvKV9bfK93vYFLXw@mail.gmail.com> >> , KILOREUX Emperex writes: >>=20 >>> As part of my participation GSOC, I have been working on an API spec = to >>> link sysctl nodes to devices. >>=20 >> 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. >>=20 >> The poster-boy example is how you get from USB bus coordinates to >> /dev/da* or /dev/{tty|cua}U* devices. >>=20 >> devd(8) seems to know the linkage and usually I resort to /etc/devd >> entries like this to make it liveable: >>=20 >> 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"; >> }; >>=20 >> 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 do a = device creation event as well (there may already be one), but there=E2=80=99= 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=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=98devnode=E2=80=99 seems the next best thing, but I=E2=80=99m = open to other names. 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 = tightly 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 last paragraph. Warner=