From owner-freebsd-arch@freebsd.org Mon Jun 6 05:59:42 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 94913B6D006 for ; Mon, 6 Jun 2016 05:59:42 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4C01092; Mon, 6 Jun 2016 05:59:41 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 501424F57A; Mon, 6 Jun 2016 05:59:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u565xWvB022385; Mon, 6 Jun 2016 05:59:33 GMT (envelope-from phk@phk.freebsd.dk) To: Warner Losh cc: KILOREUX Emperex , Koop Mast , eadler@freebsd.org, =?utf-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= , freebsd-arch@freebsd.org Subject: Re: API to link sysctl nodes to devices In-reply-to: <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> From: "Poul-Henning Kamp" References: <13621.1465030369@critter.freebsd.dk> <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22383.1465192772.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 06 Jun 2016 05:59:32 +0000 Message-ID: <22384.1465192772@critter.freebsd.dk> 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 05:59:42 -0000 -------- In message <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com>, Warner Losh = write s: >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. Many years ago I hacked up a "newbusfs" prototype, which cdevs under a device_t named tree in /device, sort of like what Sun did: /device/nexus0/acpi0/pcib1/xhci0/usbus0/uhub0/uhub3/ucom0 -> /dev/ucom0 I didn't particularly like it, and it doesn't solve the problem IMO, but it could be one way of doing it. The opposite would be plan-9 inspiration: Pair all cdevs with a partner offering the information: /dev/cuaU0 has /dev/cuaU0.info containing some lines of text with device_t linkage, serial numbers etc. >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. The device_t:dev_t mapping is [0...N]:[0...M], (people tend to forget things like multihomed disks) so that doesn't really work. >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. I think sysctl needs backpressure, it has exploded from a specialized place for "root only handles" to a general dumping ground. In particular it has a useless "all or nothing" attitude to jails. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .