From owner-freebsd-arch@freebsd.org Mon Jun 6 03:02:04 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 3E4F5B6A895 for ; Mon, 6 Jun 2016 03:02:04 +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 D1408184A; Mon, 6 Jun 2016 03:02:03 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id s64so86087860lfe.0; Sun, 05 Jun 2016 20:02:03 -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=z4toOLfyk++IIVlBRsPg+QGEyyqDGvbRai01h5LvpFs=; b=DseOn2Vr3slj9S0GLAtWSjJNR7Fex4uRQq9IOtWshtlqropsYLIyqFx4zZsWRBWhkf GiI2rki4/0Rf0nts9rp0Xh3m41XsqJF/t4awnyveVGjEmOxuVbPvMuaMnkIs6+1JRdyo llfVwuzsc85eVtZzsWoA0cMn0i3iIZumc5/SDmyMZYBv1MIWSfhjmfdNMIVeer7DT4qj ZizHcyLnTsOaBj9uZK+D8eq+DCwMWtSnDHc9MUW2OnFRX9dFF/328JQTXW+bF0p8gc+m khHlEDae0kvgc9JnuECGoCGsQ3ixeHTJspjh0M5BdMwoKrqKz1tO4vTw6rbYA9t27qhd gn+A== 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=z4toOLfyk++IIVlBRsPg+QGEyyqDGvbRai01h5LvpFs=; b=BdrTpLZNqJr7eQV5vN1r2E04G7HiAF4wJzag3T6eeYNlGGs0xhHUolw5r4RqUJT53L Kms4e5D4VOYyLZJL6omNqB7yL0fRHnYJxBO8BHJ+8NTonBnWEwdMio2mSAkR73AuZ3iV CdxKc+qvoPl56BmuFw9YDYdgVrrMlY7hsun9XzGIexRgG+RgX03UOmrI6GrA1XDs/IEw c2PoFjdlBKF/LmeTMjiPe5lVRUes9opR3a300gLfQD6y07/uV2E/lVEn0eV61VN4JUi9 +oaQPeXjqMfH7s2RNqFpbU9UMzF69PF4/AhOzgM+jv3ehptZL7ghmK1fJEyajERmndu5 gWCA== X-Gm-Message-State: ALyK8tKGVZxhqiwCQhbHEPMT2KvnjNuSL9g7e2izZPVoRTru6SeATcHZujyN0dU2hzWYF1ulKGvlk3oQqZDZhA== X-Received: by 10.25.205.198 with SMTP id d189mr786958lfg.191.1465182121572; Sun, 05 Jun 2016 20:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.16.166 with HTTP; Sun, 5 Jun 2016 20:02:00 -0700 (PDT) In-Reply-To: <6b21329d-33ea-e628-b06c-27a744c9ec09@selasky.org> References: <6b21329d-33ea-e628-b06c-27a744c9ec09@selasky.org> From: KILOREUX Emperex Date: Mon, 6 Jun 2016 04:02:00 +0100 Message-ID: Subject: Re: API to link sysctl nodes to devices To: Hans Petter Selasky Cc: freebsd-arch@freebsd.org, Koop Mast , eadler@freebsd.org, =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 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: Mon, 06 Jun 2016 03:02:04 -0000 Hey, A lot of properties can be easier for other drivers if accessed through sysctl nodes in a way relate to the device itself, for example, the PCI id for the device that could be a bit more complex to obtain otherwise. And for the ID, yeah that seems fine, but what do you think about the concept in general, got any other way to think about it ? Or do you think I should approach it any differently ? On Fri, Jun 3, 2016 at 9:24 PM, Hans Petter Selasky wrote: > Hi, > > On 06/03/16 19:14, KILOREUX Emperex wrote: > >> Hey, >> >> As part of my participation GSOC, I have been working on an API spec to >> link sysctl nodes to devices. >> >> > Can you clarify a bit what you mean by "device". The term "device" was a > bit too generic for me :-) I suppose you mean a "character device", right? > > Can you give some examples of properties for a character device, which can > be exposed trough these sysctls you propose ? > > And I cam up with few ideas that I need some feedback on before proceeding >> to the implementation on the kernel. >> >> - We need devices to have their propoer sysctl trees, and thus every >> device >> linked will have its own id as the head of its syctl tree. >> >> For example a device with id 0x94, would have it's sysctl root look like >> dev.fs.0x94 where the below parameters can be accessed after that. >> > > Would it be better to have a direct mapping between character device name, > including directories and dev.fs.xxx , like /dev/cuaU0 maps to > dev.fs.cuaU0.xxx ? > > > >> - We want to give device drivers the ability to create and delete sysctl >> nodes as they want, thus proposing a proper interface for it. >> >> >> So I have been thinking so far to enable the creation of the root for >> those >> sysctl nodes on the system initialization, to allow existing device >> drivers >> to link their device on the tree. >> >> Also we want to propose a new function similar to make_dev, supposed we >> name it make_dev_sys, that gets the device id and links it on the tree of >> existing sysctl nodes, and for the purpose of keeping track of the >> available sysctl nodes for each device, I thought of proposing a change to >> the device switching table "cdevsw" to keep systcl context tracked for the >> device. >> >> Would any modification to cdevsw break backward compatibility ? >> Please provide us with any feedback you have on this proposition and any >> defects you seeing in the logic. >> >> Your help is much appreciated. >> > > --HPS >