From owner-freebsd-arch@freebsd.org Wed Jun 8 07:22:06 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 88939B6E59A for ; Wed, 8 Jun 2016 07:22:06 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (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 4FA0E1E0F for ; Wed, 8 Jun 2016 07:22:06 +0000 (UTC) (envelope-from jean-sebastien.pedron@dumbbell.fr) Received: from 141.7.19.93.rev.sfr.net ([93.19.7.141] helo=magellan.dumbbell.fr) by mail.made4.biz with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2 (FreeBSD)) (envelope-from ) id 1bAXoS-00003j-2K for freebsd-arch@freebsd.org; Wed, 08 Jun 2016 09:22:04 +0200 Subject: Re: API to link sysctl nodes to devices To: freebsd-arch@freebsd.org References: <10046161.dJvFbDNaVq@ralph.baldwin.cx> From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= Message-ID: <3ef10748-1e8c-c937-80f2-677091e25a8f@dumbbell.fr> Date: Wed, 8 Jun 2016 09:21:59 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <10046161.dJvFbDNaVq@ralph.baldwin.cx> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="66jMK0SDvRFno4hIsQKenKLLRsXrIjbUp" 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: Wed, 08 Jun 2016 07:22:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --66jMK0SDvRFno4hIsQKenKLLRsXrIjbUp Content-Type: multipart/mixed; boundary="CbBcdVHbL3fdUSljLuFDvIHeI3WoRqmjR" From: =?UTF-8?Q?Jean-S=c3=a9bastien_P=c3=a9dron?= To: freebsd-arch@freebsd.org Message-ID: <3ef10748-1e8c-c937-80f2-677091e25a8f@dumbbell.fr> Subject: Re: API to link sysctl nodes to devices References: <10046161.dJvFbDNaVq@ralph.baldwin.cx> In-Reply-To: <10046161.dJvFbDNaVq@ralph.baldwin.cx> --CbBcdVHbL3fdUSljLuFDvIHeI3WoRqmjR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/06/2016 20:19, John Baldwin wrote: > More detail on what you actually want is needed I think. We already h= ave > sysctl device nodes for newbus devices (dev.X.y). The main reason behind this project is to be able to implement an equivalent of Linux' libudev. libudev is based on sysfs to list devices and query generic or arbitrary informations on those devices. One consumer of this API on Linux is Mesa, the userland part of the video drivers providing 3D acceleration and so on. Mesa has a file descriptor on an entry in /dev (eg. /dev/dri/card0). It passes this file descriptor to libudev to query informations such as: o the PCI ID of the graphics card o the name of the driver ("i915", "nouveau", "radeon", etc.) Another consumer is libinput, an input stack implementation not tied to the X.Org server, usable by Wayland compositors. libinput uses libudev to enumerate input devices and query them, but I never studied what exactly it needs. Today, on FreeBSD, Mesa uses the "hw.dri" sysctl tree (which is specific to graphics card) to get the required informations. But we can't do that for any kind of devices. To sum up, we need a way to list devices and get various informations, in a non-graphics-card-specific way. There is devinfo(3) but I don't see a way to associate a result from devinfo(3) to a file descriptor from /dev. Likewise for the "dev" sysctl tree. > The drm2 code insists on using its own private tree instead of=20 > dev.drmn.0.y though which might be the source of some confusion. I agree it should be unifed. > If the goal is to know which device_t a > given cdev is associated with, I think having a way to ask that and the= n use > nodes for the device_t is more straightforward than having an indirecti= on > with a separate sysctl tree with opaque cookies for names. >=20 > (That is, if you had a 'QUERY_DEVICET_NAME' ioctl that character device= > drivers could optionally implement. Note that only the device driver > really knows the mapping from cdev to device_t. We could perhaps provi= de > a wrapper where you could add the device_t as an arg via make_dev_s() a= nd > have the devfs ioctl handler handle QUERY_DEVICET_NAME in that layer us= ing > the arg passed to make_dev_s(). I would perhaps have the ioctl return = the > name and unit broken out so it is easier to generate the sysctl path.) I see. That's a good idea, thank you! We'll discuss this further. --=20 Jean-S=E9bastien P=E9dron --CbBcdVHbL3fdUSljLuFDvIHeI3WoRqmjR-- --66jMK0SDvRFno4hIsQKenKLLRsXrIjbUp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJXV8eXAAoJEDnpl2Gl/ZTMKS4P/1QJ+gycsWgtoTIJQWNdZi4V EdgKPYrm/Uw5pBdhGazdLsF8kAuIANZ3KxMDQs0E6RccRGNZGTUdOyKRLjK5sezV +/6sieYsm+Csc8N4EaGIbt5b/s4GkVuDQEXklR7GPPaLnUpCutQYF7indg8JX/TI Qj3qpUUNAieo830LAoKBgIJLqzrsH5Df6Wnsp22XYeOxiGvtLIfMTc3GOWG0FbkZ nLaWnMOxEhOb6gHAJBADoPM2gS02uh08SW6r/4GOxaGVr0Oarmd/4eqx3ceY2A15 9/7MncxwP/r5noXqSSQ/Pg30gCFsP10cz1YWkevxweHggKjWGUjw29tRmlEBtNYv qi4PhtHokjvqlaiK/Ccxe+qhmxALCdFfo8YVntzwmouOqvYz85qf13vDbdi1LS8U v+EgpfFhKpMypkkSX8idfHReWwIB4vS/rPOnpACDCzo0DSJWY4JeRI2x+1gaGfWv WRoYZBlKq57zeBnjRWEw2gTr7kyN2oRqpNSl6Awm2dfl8AuBPxqbb0X1QwmXzQjm Ld3YXVuquAdIOI2KriF0M5yjFLGs176mxzQvzgRmYkggogqJOhZ6vxbQwjyv3fks Ohef3z67g5WaYleIm/s+0wiHY/5yYj6GiYNjUI3CfcDBSVPpLJuGsxbKFbLa8XXL xiQVsiYIZoAva88fIydo =+U6e -----END PGP SIGNATURE----- --66jMK0SDvRFno4hIsQKenKLLRsXrIjbUp--