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 > From owner-freebsd-arch@freebsd.org Mon Jun 6 03:07:19 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 1E1D6B6AA38 for ; Mon, 6 Jun 2016 03:07:19 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 95E181B25; Mon, 6 Jun 2016 03:07:18 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id s64so86131093lfe.0; Sun, 05 Jun 2016 20:07:18 -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=hBJIwfQTZQ39asciDCwI1XMckybRQPZFiBMgBmPJhsQ=; b=QVVQhJKCAijoG1/NANiapugG9it/mkEIV0xW+VL9zzghJapVdEOCuS5THrt1rw5tif Kmh35nH0C5xpucCePccvF9qdX7u5Gz10rrTJlP42V5m2jtx57NI2H2y3gYGqWY5a2cEp XqWX5NraUIVrCRnmRd6QAbTW9lTFwSC8h3McXo6sQnKmgMsCBxDrxgupFuCTw/C7Qv93 /dM/rywAApDF9jtU67hTEniEMuE2CDbZA7AfdaiZgz5IG0w4jo0vcnE4NYogUkXEszz6 M98WqEr5KledOhiUK5ddDUGpB8RmBvs9k57TX38oCZU3sMenUS7y2EmU6nRW1AKgQboc EbDA== 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=hBJIwfQTZQ39asciDCwI1XMckybRQPZFiBMgBmPJhsQ=; b=AG99rcbnYtQ68Qj2LrD2ANFQlGpMBUNFB0AKDjOiBpln0SxgXYoCw3oJlwg1flzCK5 rLi0lFtv0sJfjjWDeHOGOVHx9jMhJKbZIxk/9Ajjd1bSlOseSrv+3w/DAfiqN9eHdEpD hVoZHEO5a6Lec8F8968Au1MfGAVUk83dbzk+A1qxJ+ySb6mtLzFU90p0bd2BPvOjWPR1 jjSPlwJaSOfLu7vgBMOLuIj9KRmTNbL+D88xt3so/NrPSkSuvE5D9LCZtgrGaHbWGIhP 1fBubbioIf34dt0mlKIAW3xmpz27QC5zvhEL0YyLzAloqzhmozeF3lpw8+7DJ4vHb6Wy yi1w== X-Gm-Message-State: ALyK8tI46y7z6K/gGtwH7p8uAJ3JUhT7fQAJ4cRG/++Yk51GZq6+S4WJzyDeLjGpf0vOLxXNjg6USNxhivQ41A== X-Received: by 10.25.30.213 with SMTP id e204mr536779lfe.71.1465182436850; Sun, 05 Jun 2016 20:07:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.16.166 with HTTP; Sun, 5 Jun 2016 20:07:16 -0700 (PDT) In-Reply-To: <13621.1465030369@critter.freebsd.dk> References: <13621.1465030369@critter.freebsd.dk> From: KILOREUX Emperex Date: Mon, 6 Jun 2016 04:07:16 +0100 Message-ID: Subject: Re: API to link sysctl nodes to devices To: Poul-Henning Kamp 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:07:19 -0000 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 wrote: > -------- > In message < > CAN1JrQ2dd0WZi0_aaNdqH9xdy292tP2DYLxvKV9bfK93vYFLXw@mail.gmail.com> > , 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"; > }; > > > -- > 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. > 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= 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= . From owner-freebsd-arch@freebsd.org Mon Jun 6 19:11:46 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 B17A5B6D675 for ; Mon, 6 Jun 2016 19:11:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C7F51AF5; Mon, 6 Jun 2016 19:11:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 352DDB9A0; Mon, 6 Jun 2016 15:02:51 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: KILOREUX Emperex , Koop Mast , eadler@freebsd.org, =?ISO-8859-1?Q?Jean=2DS=E9bastien_P=E9dron?= Subject: Re: API to link sysctl nodes to devices Date: Mon, 06 Jun 2016 11:19:51 -0700 Message-ID: <10046161.dJvFbDNaVq@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 06 Jun 2016 15:02:51 -0400 (EDT) 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 19:11:46 -0000 On Friday, June 03, 2016 06:14:45 PM KILOREUX Emperex wrote: > Hey, > > As part of my participation GSOC, I have been working on an API spec to > link sysctl nodes to devices. > > 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. > > - 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. More detail on what you actually want is needed I think. We already have sysctl device nodes for newbus devices (dev.X.y). The drm2 code insists on using its own private tree instead of dev.drmn.0.y though which might be the source of some confusion. If the goal is to know which device_t a given cdev is associated with, I think having a way to ask that and then use nodes for the device_t is more straightforward than having an indirection with a separate sysctl tree with opaque cookies for names. (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 provide a wrapper where you could add the device_t as an arg via make_dev_s() and have the devfs ioctl handler handle QUERY_DEVICET_NAME in that layer using 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.) -- John Baldwin From owner-freebsd-arch@freebsd.org Mon Jun 6 19:34:57 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 B8FF3B6DE38 for ; Mon, 6 Jun 2016 19:34:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 9CE761B7D for ; Mon, 6 Jun 2016 19:34:57 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: c35d451a-2c1d-11e6-8929-8ded99d5e9d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 6 Jun 2016 19:35:02 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u56JYm8V006675; Mon, 6 Jun 2016 13:34:48 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1465241688.1188.18.camel@freebsd.org> Subject: Re: API to link sysctl nodes to devices From: Ian Lepore To: Warner Losh , KILOREUX Emperex Cc: Koop Mast , Poul-Henning Kamp , eadler@freebsd.org, =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= , freebsd-arch@freebsd.org Date: Mon, 06 Jun 2016 13:34:48 -0600 In-Reply-To: <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> References: <13621.1465030369@critter.freebsd.dk> <070D3C32-9631-49AD-85FB-53A4865AFA08@bsdimp.com> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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 19:34:57 -0000 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’s a problem. We could do a > device creation event as well (there may already be one), but there’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’d 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 ‘devnode’ is just a name, I’m > agnostic, but given that dev is already taken (and its an API for > many device drivers, so changing it would be difficult) ‘devnode’ > seems the next best thing, but I’m 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=0x9e88 product=0x9e8f devclass=0x00 devsubclass=0x00 sernum="FTVB685F" release=0x0500 mode=host intclass=0xff intsubclass=0xff intprotocol=0xff ttyname=U0 ttyports=1 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’t destroyed when the > device_t created it gets detached. > > 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. > > 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" > 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" > > > From owner-freebsd-arch@freebsd.org Tue Jun 7 19:52:37 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 A2753B6D7A2 for ; Tue, 7 Jun 2016 19:52:37 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 0E77813C1; Tue, 7 Jun 2016 19:52:37 +0000 (UTC) (envelope-from kiloreux@gmail.com) Received: by mail-lf0-x22a.google.com with SMTP id s64so122256686lfe.0; Tue, 07 Jun 2016 12:52:36 -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=A+q6aExm+J0awV1bj2Y6jZ0MQxCgi2htHrE5se4FYzg=; b=UHM5C9HOiTFexAUrTEqRQrXF06oZtNu8lyxB5VuED73DDzTtyhv3LUL/iBS2B334qe Y2VaD0NzrzX+PIXWyFjpBj46xZy6xFIQ3I3qavZVzGUQCbuH5TyFFB0BuO7IV4FeDuqR jSuHHlZSScziMrmfRZCZ5ZnzMIstm14lNh9JVZDU32245mh/qgsbIUkWCLse3DeTzc4g Bl2/txz2Rgi/e35TM+dr83p6oGIx3v+tIreV/bbkGC5U/VgJk1pAWF7mWOK5R0YOAq0t SBGVmPxZdZJU6NIbBYp8Akym07ldpBmOiufQVq+cr1mbsZ0ZdUM3GxdByVdJnLUOYb4f TDpg== 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=A+q6aExm+J0awV1bj2Y6jZ0MQxCgi2htHrE5se4FYzg=; b=IXKN470u4XYA088e8vyRypCF5vVMI8AFFpOCBRtDBFAVZJbhCLQM22Gl6ZUPv+ybOm mGgsFliu+87EQm0vJtebJtFDbhYoTICCnsISIt/HZ+dcMy3AwnkNgLtC0W3+JFwuPDsC ChaLqng4JtyclhoxlMHVPfo77tT2+rrGrbcJ+Bldadj3ca7MEPEIUC4alQ9Dy46vXN+t dBn5dyw6Q7ZOD14fN2Tob7rmVlDoIN+UKk5rA6kVTMysJCUJk1f9BWP4rgRjDpm0yY5W ZdmYXByIp9BNSA5gE0XzH8IMxgTAZtgeGcUpkDSntXAlvzjOAihxruYpLrXv5PdGzO+R +H+w== X-Gm-Message-State: ALyK8tIBpbkgxO5E6s30oJZJpEp6UfQWgbrMe6qVrXpCUTX3TUQ2Ny2Oc/BXOYclJKpUUSasjXcA4VgUMu7wVQ== X-Received: by 10.25.207.1 with SMTP id f1mr2816368lfg.39.1465329155251; Tue, 07 Jun 2016 12:52:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.16.166 with HTTP; Tue, 7 Jun 2016 12:52:34 -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:52:34 +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:52:37 -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" > > > 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-- From owner-freebsd-arch@freebsd.org Thu Jun 9 08:50:24 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 8275AAEE88F for ; Thu, 9 Jun 2016 08:50:24 +0000 (UTC) (envelope-from bounces@mailvm.ru) Received: from mailvm.ru (mailvm.ru [185.144.28.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 144111ECB for ; Thu, 9 Jun 2016 08:50:23 +0000 (UTC) (envelope-from bounces@mailvm.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailvm.ru; s=mail; h=Content-Type:MIME-Version:List-Owner:List-Subscribe:List-Unsubscribe:List-Help:Message-ID:Subject:From:To:Date; bh=GoCbJxfve+1wAT7xTMvs4g0Eb5fI5Y4bndA10o2ce3M=; b=dEA124tlxgpimNvOPf5IkaNBGQTmhxTPpqe7IrqfdM0lDHGK4mWFEtprwi9jlfwnN2VU+CxHc4uJleIQun2Jnb4uFLPc0NbydpetDpQdTCqqNHXrftCnB1ENSJGYxGAT8OS+O89fWGaTeGrdZNOSzj6kW5qS97O1H63ErEkuKfg=; Received: by mailvm.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1bAt7Q-0008Pf-Dk; Thu, 09 Jun 2016 09:07:04 +0300 Date: Thu, 9 Jun 2016 09:07:04 +0300 To: freebsd-arch@freebsd.org From: =?UTF-8?B?0J7RgNCz0LrQvtC80LjRgtC10YI=?= Subject: =?UTF-8?B?0JjRgdC60LvRjtGH0LjRgtC10LvRjNC90L4g0YXQvtGA0L7RiNC+INC+0YI=?= =?UTF-8?B?0LTQvtGF0L3Rg9GC0Ywg0YLRgNGD0LTQvtCy0YvQvCDQutC+0LvQu9C10Lo=?= =?UTF-8?B?0YLQuNCy0LDQvA==?= Message-ID: X-Mailer: PHPMailer 5.2.14 (https://github.com/PHPMailer/PHPMailer) X-phpList-version: 3.2.4 X-MessageID: 62 X-ListMember: freebsd-arch@freebsd.org Precedence: bulk Bounces-To: bounces@mailvm.ru List-Owner: MIME-Version: 1.0 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 List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 08:50:24 -0000 /=D0=9B//=D1=8C=D0=B3=D0=BE=D1=82=D0=BD=D1=8B=D0=B5 =D0=BF=D1=83=D1=82= =D0=B5=D0=B2=D0=BA=D0=B8 =D0=B4=D0=BB=D1=8F =D1=82=D1=80=D1=83=D0=B4=D0= =BE=D0=B2=D1=8B=D1=85 =D0=BA=D0=BE=D0=BB=D0=BB=D0=B5=D0=BA=D1=82=D0=B8=D0=B2=D0=BE=D0=B2, =D0= =BF=D1=80=D0=BE=D1=84=D1=81=D0=BE=D1=8E=D0=B7=D0=BD=D1=8B=D1=85 =D0=B8 = =D0=BE=D0=B1=D1=89=D0=B5=D1=81=D1=82=D0=B2=D0=B5=D0=BD=D0=BD=D1=8B=D1=85 =D0=BE=D1=80=D0=B3=D0=B0=D0=BD=D0=B8=D0=B7=D0=B0=D1=86=D0=B8=D0=B9, =D0= =B0 =D1=82=D0=B0=D0=BA=D0=B6=D0=B5 =D0=B2=D1=81=D0=B5=D1=85 =D0=B6=D0=B5= =D0=BB=D0=B0=D1=8E=D1=89=D0=B8=D1=85 =D0=B2 =D1=87=D0=B0=D1=81=D1=82=D0=BD=D1=8B=D0=B5 =D0=BE=D1=82=D0=B5=D0=BB=D0= =B8 =D0=A1=D0=BE=D1=87=D0=B8 =D0=B8 =D0=90=D0=B4=D0=BB=D0=B5=D1=80=D0=B0! / /=D0=A1=D0=A3=D0=9F=D0=95=D0=A0=D0=90=D0=9A=D0=A6=D0=98=D0=AF!!!/ /=D0=94=D0=BE 20 =D0=B8=D1=8E=D0=BD=D1=8F =D1=81=D0=BA=D0=B8=D0=B4=D0=BA= =D0=B8 =D0=BD=D0=B0 =D0=B2=D1=81=D0=B5 =D0=BD=D0=B0=D1=88=D0=B8 =D0=BE= =D1=82=D0=B5=D0=BB=D0=B8:/ *=D0=BD=D0=B0 =D0=B8=D1=8E=D0=BD=D1=8C - 20%, =D0=BD=D0=B0 =D1=81=D0=B5= =D0=BD=D1=82=D1=8F=D0=B1=D1=80=D1=8C - 30%, =D0=BD=D0=B0 =D0=BE=D0=BA=D1= =82=D1=8F=D0=B1=D1=80=D1=8C - 40%* =D0=92=D1=81=D1=8F =D0=B8=D0=BD=D1=84=D0=BE=D1=80=D0=BC=D0=B0=D1=86=D0= =B8=D1=8F =D0=B7=D0=B4=D0=B5=D1=81=D1=8C=0A -- This message was sent to freebsd-arch@freebsd.org by petrov@mailvm.ru To forward this message, please do not use the forward button of your email application, because this message was made specifically for you only. Instead use the forward page=0A in our newsletter system. To change your details and to choose which lists to be subscribed to, visit your personal preferences page=0A or you can opt-out completely=0A from all future mailings. =D0=98=D0=B7=D0=BC=D0=B5=D0=BD=D0=B8=D1=82=D1=8C =D0=BF=D0=B0=D1=80=D0= =B0=D0=BC=D0=B5=D1=82=D1=80=D1=8B =D1=80=D0=B0=D1=81=D1=81=D1=8B=D0=BB= =D0=BA=D0=B8, =D0=B2 =D1=82=D0=BE=D0=BC =D1=87=D0=B8=D1=81=D0=BB=D0=B5 =D0=BE=D1=82=D0=BF=D0=B8=D1=81=D0=B0=D1=82=D1=8C=D1=81=D1=8F =D0=BE=D1= =82 =D1=80=D0=B0=D1=81=D1=81=D1=8B=D0=BB=D0=BE=D0=BA, =D0=92=D1=8B =D0= =BC=D0=BE=D0=B6=D0=B5=D1=82=D0=B5 =D0=BD=D0=B0 =D1=81=D0=B2=D0=BE=D0=B5=D0=B9 =D0=BF=D0=B5=D1=80=D1=81=D0=BE=D0=BD=D0= =B0=D0=BB=D1=8C=D0=BD=D0=BE=D0=B9 =D1=81=D1=82=D1=80=D0=B0=D0=BD=D0=B8= =D1=86=D0=B5 =D0=BD=D0=B0=D1=81=D1=82=D1=80=D0=BE=D0=B5=D0=BA =D0=B8=D0=BB=D0=B8 =D0=92=D1=8B =D0=BC=D0=BE=D0=B6=D0=B5=D1=82=D0=B5 =D0= =BF=D1=80=D0=BE=D1=81=D1=82=D0=BE =D0=BE=D1=82=D0=BF=D0=B8=D1=81=D0=B0= =D1=82=D1=8C=D1=81=D1=8F =D0=BE=D1=82 =D1=8D=D1=82=D0=BE=D0=B9 =D1=80=D0=B0=D1=81=D1=81=D1=8B=D0= =BB=D0=BA=D0=B8. =20 -- powered by phpList, www.phplist.com -- From owner-freebsd-arch@freebsd.org Thu Jun 9 08:51:12 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 BF5D4AEE8F7 for ; Thu, 9 Jun 2016 08:51:12 +0000 (UTC) (envelope-from bounces@mailvm.ru) Received: from mailvm.ru (mailvm.ru [185.144.28.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 778161042 for ; Thu, 9 Jun 2016 08:51:12 +0000 (UTC) (envelope-from bounces@mailvm.ru) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mailvm.ru; s=mail; h=Content-Type:MIME-Version:List-Unsubscribe:Message-ID:Subject:From:To:Date; bh=zoxY4ut1B9/xFKIAmMihhOUo55r+q85BWRHGOrMmMiM=; b=LxPmzhAMGzVEOArQAxHLdTqABLNEG+muwdhX8wrhFNMDKRT7E+Et+d0Skni3+FI68cpYDpPD3YqRAoAN+P9ywv7VDh3HteG0gnDoMeyxqeIpJCQBq3wkL9kxid7yGLudmmFDBIYdyV6coWvPQK13qkEBlu/u9qMTEILTkb0Npgg=; Received: by mailvm.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1bAvgE-0001q5-2b; Thu, 09 Jun 2016 11:51:10 +0300 Received: from mailvm.ru [185.144.28.251] by mailvm.ru with HTTP; Thu, 09 Jun 2016 11:51:09 +0300 Date: Thu, 9 Jun 2016 11:51:09 +0300 To: freebsd-arch@freebsd.org From: =?UTF-8?B?0J7RgNCz0LrQvtC80LjRgtC10YI=?= Subject: Goodbye from our Newsletter Message-ID: <44a8d70debe7c0d4230a8f7f562a4e9d@mailvm.ru> X-Mailer: PHPMailer 5.2.14 (https://github.com/PHPMailer/PHPMailer) X-phpList-version: 3.2.4 X-MessageID: systemmessage X-ListMember: freebsd-arch@freebsd.org Precedence: bulk Bounces-To: bounces@mailvm.ru MIME-Version: 1.0 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 List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 08:51:12 -0000 =20 Goodbye from our Newsletter, sorry to see you go. You have been unsubscribed from our newsletters. This is the last email you will receive from us. Our newsletter system,= =0AphpList, will refuse to send you any further messages, without manual intervention= =0Aby our administrator. If there is an error in this information, you can re-subscribe: please go to http://mailvm.ru/lists/?p=3Dsubscribe and follow the steps. Thank you =20 =20 From owner-freebsd-arch@freebsd.org Thu Jun 9 17:41:54 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 E5CBDB701A8 for ; Thu, 9 Jun 2016 17:41:54 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 AF50E1D96 for ; Thu, 9 Jun 2016 17:41:54 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x230.google.com with SMTP id z189so160616008itg.0 for ; Thu, 09 Jun 2016 10:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:from:to:content-transfer-encoding:mime-version :subject:date; bh=clAIGd8GUl5xb9JA6dQ2FbnhQd+WXfibEw76BOQSg5s=; b=RJVBnBMAW3hI3jEXcsH+QIfMcLsGj4+ZAIg5dzLMVZ+7091CBzjUsPNrlsWew1ZkIK nnBLBcLRIzbCgMJQgiqpjrAatD0M0HKPGaRY+bPpxbjEzDDjK3LE5avykBr+jMQMTVji JidYvfc2IrlgEcJCQRaVLRTGIzFR/I9b21VPNgIEw0FlsE6z6ZI2qZhpe5jBwR8jPi1c mPYJm6itU4hERdbLBpQtEptDX4ZJ5lDDyBrFG3nPnavn+qhtoJ60BCHaQGfqBOf8u3Av TKrHOehLeK1Svwt9VzcgAwS790diTUwMy0s3v6IEXYJP5xdjCh72xLCXsXJpHrB8hQvh LL7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:from:to :content-transfer-encoding:mime-version:subject:date; bh=clAIGd8GUl5xb9JA6dQ2FbnhQd+WXfibEw76BOQSg5s=; b=mFhFNNNBAYAGOmXsz39E8zf0O+cXQjrtNf7wNwjP5vGMeextnItgf9V0BWwm9G8NP1 M9tuuTrmiVRIA4PW3fSnP5okIboLnLELsjyDpMMm5D6C2R0/Zk5w2V4tPJYDBfHd5LM4 S0mQaNE+NtZka/TGBrMCp9750r7SuNOa2khp+mjV21h1MlqYWWHoY9CJVP4k88vzFX+3 LqCdI8CuvmrNg1R7TUvzkJL/LAhGM/HKqzy19MUqzdeDAcSBML8vqKFbrPJ2JEmPiRW1 AKh7dSF/8lpLcGi78FQBD5wQBW9vpkvb70RW92+BAGlpS8sWPgIwCIEgZ0QgJVptitkQ MPDA== X-Gm-Message-State: ALyK8tLFTm1YTzAgDjfhEIDv4cFkbiNKsXtLyYmyBhT9gl10lg+qcfxUpC1968o1uEdF+w== X-Received: by 10.36.124.65 with SMTP id a62mr20116849itd.33.1465494114136; Thu, 09 Jun 2016 10:41:54 -0700 (PDT) Received: from [10.65.211.198] ([137.122.64.8]) by smtp.gmail.com with ESMTPSA id c65sm3686935iof.9.2016.06.09.10.41.53 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 09 Jun 2016 10:41:53 -0700 (PDT) Sender: Justin Hibbits Message-Id: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> From: Justin Hibbits To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: PowerPC 64-bit time_t Date: Thu, 9 Jun 2016 13:41:52 -0400 X-Mailer: Apple Mail (2.936) 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: Thu, 09 Jun 2016 17:41:55 -0000 At the devsummit earlier today I mentioned for FreeBSD 12 wanting 64- bit time_t across the board. It was pointed out that the only ones with 32-bit time_t are i386 and powerpc (32-bit). I've made the changes necessary for at least kernel (world is still building right now), but it's obviously an ABI and KBI incompatible change. Addressing KBI is a nonissue, as that's expected to break at major releases. ABI is another issue. I'm unsure how to properly address ABI breakage -- bumping libc's .so version, or reversion all symbols that use something with time_t, or something else. If I can address it before the code freeze, it could be done for FreeBSD 11, which leaves about 6 hours from now. Any thoughts? - Justin From owner-freebsd-arch@freebsd.org Thu Jun 9 19:31:36 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 755D1B7032D for ; Thu, 9 Jun 2016 19:31:36 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 540C91FC6; Thu, 9 Jun 2016 19:31:36 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id F3C295A9F27; Thu, 9 Jun 2016 19:31:28 +0000 (UTC) Date: Thu, 9 Jun 2016 19:31:28 +0000 From: Brooks Davis To: Justin Hibbits Cc: freebsd-arch@freebsd.org Subject: Re: PowerPC 64-bit time_t Message-ID: <20160609193128.GB34204@spindle.one-eyed-alien.net> References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> User-Agent: Mutt/1.6.1 (2016-04-27) 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: Thu, 09 Jun 2016 19:31:36 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 09, 2016 at 01:41:52PM -0400, Justin Hibbits wrote: > At the devsummit earlier today I mentioned for FreeBSD 12 wanting 64-=20 > bit time_t across the board. It was pointed out that the only ones =20 > with 32-bit time_t are i386 and powerpc (32-bit). I've made the =20 > changes necessary for at least kernel (world is still building right =20 > now), but it's obviously an ABI and KBI incompatible change. =20 > Addressing KBI is a nonissue, as that's expected to break at major =20 > releases. ABI is another issue. I'm unsure how to properly address =20 > ABI breakage -- bumping libc's .so version, or reversion all symbols =20 > that use something with time_t, or something else. If I can address =20 > it before the code freeze, it could be done for FreeBSD 11, which =20 > leaves about 6 hours from now. For i386, the only practical option is going to be a new TARGET_ARCH and likely ELF machine type. For powerpc, I'd be tempted to just break the ABI and leave a way to switch it back for people who build products where the ABI change is an issue. -- Brooks --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXWcQQAAoJEKzQXbSebgfAlgwH/i/dMVG5k8zIiA4H1Nlcm+nz /zUIh9W0FYSIyP9iZjO3m0khnvqPZhf0H6tossmItgkQq9FyVGQWBiswzv3Xxqp5 sRvE863z8smCrMG7E39WazpwPLmaRVUu3wgFLir4aaI14bsYIbNsjRPEMdDJj3x8 J+6zgt2fEFiFpdmTQayQdV2PI5gL9VhFEzfnZu3vDbqNvQ4mSx5U0spedGqG+NoW GfnPQS4ZolNQgBzMpzJtXSlboKGn8OSzEGoFIyOWi6q5Gr4y1DeY38qp3i6SWwf0 zM+3lQgBXeeynGYUuOcWaEjC8sV/r6ave57r7nidzT1jwzHUS+BHbIFgWBVGwFQ= =10uM -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-arch@freebsd.org Thu Jun 9 19:37:46 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 1B2F7B7041F for ; Thu, 9 Jun 2016 19:37:46 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 E02A511D8 for ; Thu, 9 Jun 2016 19:37:45 +0000 (UTC) (envelope-from dfr@rabson.org) Received: by mail-oi0-x230.google.com with SMTP id e72so79826582oib.1 for ; Thu, 09 Jun 2016 12:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rabson-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EXNLPLlioLfoIqUSNqAGQ3AW3iO+mI++koN9Z4r/Oo0=; b=bi7aEeHbGw1HTjFZ6wAVa6BymrPYDsawUsZ39dUiiDp/h5U4oTKcOxdXPWPEztQmPN cdGKHU/ZdBCmnKB6WQppmK9+ug8BQIG0jMNeQw8fPYlnWJKI+HmOgy7gqTLuuJiKjpXa /oF52tHc1mXAoGlAVxN3A+mSpECbn6YHPniDzdK0cirUZQWSrgxbWLWJkNAECtbricLj gL4VQFahAoDRKNgkviXfPTGZ8RB5kqtkO80VKtOIl6AYYoDB/vroi+I2AwjpNu9NcIqN Y5gWR5Ylql00Xsj5f4KsJhJ5FcpDpi97YNFYYWQaOFznHG9eLBNXDnc15xnYpuHJcvXT QblA== 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=EXNLPLlioLfoIqUSNqAGQ3AW3iO+mI++koN9Z4r/Oo0=; b=YX1wFo3OpcncOSEdZHvhpH9YUqZhqeIoYkrhDIgqjQqpt+r58B+XQJNBlXma6gPxtW vw+mugnlghmcRC5zFQPqYDvlIu4thg9UfhUFRFrYRFrioIow4/mQ6kBzlUveIkOJsoAm Fn1vnyRQnmEAD0lV8jf8T4mY2piRj00deseWGwGFF0TlN1ZkF6ihDjU1Ft6ASvKhuAeh xzqKxH/mAW6yAI8EFz0nfhzVpbPYgWAtklV+1RXHT8v4onfxMoc8mTPQDgoaTQBr700N pTmci9Zj3/JOFK84RMaU1zua7LjQehOXmgWLAEFX+CVc1Kge6keOpMmbra4RpWx9ufsc 4KPw== X-Gm-Message-State: ALyK8tJEfU5tWQzCZmrkySqgKKqnuwvYtBlUkWZk6H7HBP1SNrOgiLz1nqQYC3hlpx5156bOmivScqBR3k/I4w== X-Received: by 10.202.85.17 with SMTP id j17mr5351151oib.60.1465501064991; Thu, 09 Jun 2016 12:37:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.98.226 with HTTP; Thu, 9 Jun 2016 12:37:44 -0700 (PDT) In-Reply-To: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> From: Doug Rabson Date: Thu, 9 Jun 2016 15:37:44 -0400 Message-ID: Subject: Re: PowerPC 64-bit time_t To: Justin Hibbits Cc: FreeBSD Arch 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: Thu, 09 Jun 2016 19:37:46 -0000 Well you have to maintain the kernel's syscall ABI, which basically means adding new syscalls for anything which is affected. On 9 June 2016 at 13:41, Justin Hibbits wrote: > At the devsummit earlier today I mentioned for FreeBSD 12 wanting 64-bit > time_t across the board. It was pointed out that the only ones with 32-bit > time_t are i386 and powerpc (32-bit). I've made the changes necessary for > at least kernel (world is still building right now), but it's obviously an > ABI and KBI incompatible change. Addressing KBI is a nonissue, as that's > expected to break at major releases. ABI is another issue. I'm unsure how > to properly address ABI breakage -- bumping libc's .so version, or > reversion all symbols that use something with time_t, or something else. > If I can address it before the code freeze, it could be done for FreeBSD > 11, which leaves about 6 hours from now. > > Any thoughts? > > - Justin > _______________________________________________ > 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" > From owner-freebsd-arch@freebsd.org Thu Jun 9 20:09: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 F12F5B70C77 for ; Thu, 9 Jun 2016 20:09:42 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 B950C19A9 for ; Thu, 9 Jun 2016 20:09:42 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id h190so44341330ith.1 for ; Thu, 09 Jun 2016 13:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:cc:message-id:from:to:in-reply-to:mime-version:subject:date :references; bh=o1k4Dszd1fEJg/HF0G4HsxcOFl50zqkuC4UqGvAAWYM=; b=qsuG0/vaqGyee8nsHlBrDWOmvAfDEgNnyykAYnovGMfJbL3vwXCVIxDhcEngqlaZE3 qh4rAhilIQkmTh6KxzWko7tUNRJ7d4hkMZZESYJrKFD9uuXkK37/xnV9MyFbAiD0NRya /dFmRCd2o3SlWl1H8ZaAkO828MlVuneuQ0xLqp5RjWA/A03zmX4HnzaJFnP3bL5m8yti giLPaqXd591iHPQGybrSSJdGwFhVYJVek9b1BwscBBKXB/2jTsEQdzGl3oEvrvZjFlGv 2yp7X+o+vH5ql/uuhfFe9IdzPfMSd+6Wp64f9knSkG+85QdPkLgq6yzf4RwT4siJs9rC 0WhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:cc:message-id:from:to:in-reply-to :mime-version:subject:date:references; bh=o1k4Dszd1fEJg/HF0G4HsxcOFl50zqkuC4UqGvAAWYM=; b=PZafc4k2NjnKHeJN1HvyuikXU/W59VNY89tnwq7qgAzNnxikmxl09tQke31vAYQDTc sKmzQxqUmDmIneZR3kAHbdkRbrYEKiF2560NnyKgkzTviVgaE+sJvzhVdNEPcH9ZioZQ Y01q/cVL/QPOtoHcy9WS1MKG54iwMk9uAbiAJ9a6Tn9QsbH8jhxvHL8GdCXBWZPNaHRd 1wpdc0kc6pM2vc0DcN+ggj0ZExD6bOnN/aJPPFpw162l8w2J7MTFHiVdtAE1v8L8wmKN qNGUCaTyY2b8Qvi/1FInX0RapIYPMsxmHqaYM7zch69q3qr0GZ7FPMl81+qpGL3KdcwI +U9w== X-Gm-Message-State: ALyK8tIJ6o5dqKfshzCfmuqbYe+/XAAlu3XYn5C5l4KbunUGeLGtFJC/OmvKZH4B1nFlxA== X-Received: by 10.36.55.138 with SMTP id r132mr25533610itr.73.1465502982162; Thu, 09 Jun 2016 13:09:42 -0700 (PDT) Received: from [10.65.211.198] ([137.122.64.8]) by smtp.gmail.com with ESMTPSA id 142sm3916359itk.12.2016.06.09.13.09.41 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 09 Jun 2016 13:09:41 -0700 (PDT) Sender: Justin Hibbits Cc: FreeBSD Arch Message-Id: <8CD57763-E623-480F-A2E4-3145A3C22F86@freebsd.org> From: Justin Hibbits To: Doug Rabson In-Reply-To: Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: PowerPC 64-bit time_t Date: Thu, 9 Jun 2016 16:09:40 -0400 References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> X-Mailer: Apple Mail (2.936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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: Thu, 09 Jun 2016 20:09:43 -0000 This would only be needed if syscall ABI compatibility is required, right? Considering the current support state and userbase of powerpc, a simple binary option of 32 vs 64 should be sufficient, I believe. For i386 it's a different story, since it's much more widely used (and tier1) so backwards compatibility is 100% necessary. - Justin On Jun 9, 2016, at 3:37 PM, Doug Rabson wrote: > Well you have to maintain the kernel's syscall ABI, which basically > means adding new syscalls for anything which is affected. > > On 9 June 2016 at 13:41, Justin Hibbits wrote: > At the devsummit earlier today I mentioned for FreeBSD 12 wanting 64- > bit time_t across the board. It was pointed out that the only ones > with 32-bit time_t are i386 and powerpc (32-bit). I've made the > changes necessary for at least kernel (world is still building right > now), but it's obviously an ABI and KBI incompatible change. > Addressing KBI is a nonissue, as that's expected to break at major > releases. ABI is another issue. I'm unsure how to properly address > ABI breakage -- bumping libc's .so version, or reversion all symbols > that use something with time_t, or something else. If I can address > it before the code freeze, it could be done for FreeBSD 11, which > leaves about 6 hours from now. > > Any thoughts? > > - Justin > _______________________________________________ > 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" > From owner-freebsd-arch@freebsd.org Thu Jun 9 20:11:01 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 E9ECBB70CE9 for ; Thu, 9 Jun 2016 20:11:01 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D96CF1ACB for ; Thu, 9 Jun 2016 20:11:01 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u59K09dD009900 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 9 Jun 2016 13:00:10 -0700 Subject: Re: PowerPC 64-bit time_t To: freebsd-arch@freebsd.org References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> <20160609193128.GB34204@spindle.one-eyed-alien.net> From: Nathan Whitehorn Message-ID: Date: Thu, 9 Jun 2016 13:00:09 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160609193128.GB34204@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb4DBIvUf06hjoz2o7rK2YNuPDbcDdapAGqFlbsTui3MPjYYhOFUngepkM937bBXptOHh41Yi0DLPb57KOM13QxcMt03rUqNRs= X-Sonic-ID: C;lrgcxXwu5hGoVLEI9Bb3tg== M;nOp/xXwu5hGoVLEI9Bb3tg== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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: Thu, 09 Jun 2016 20:11:02 -0000 On 06/09/16 12:31, Brooks Davis wrote: > On Thu, Jun 09, 2016 at 01:41:52PM -0400, Justin Hibbits wrote: >> At the devsummit earlier today I mentioned for FreeBSD 12 wanting 64- >> bit time_t across the board. It was pointed out that the only ones >> with 32-bit time_t are i386 and powerpc (32-bit). I've made the >> changes necessary for at least kernel (world is still building right >> now), but it's obviously an ABI and KBI incompatible change. >> Addressing KBI is a nonissue, as that's expected to break at major >> releases. ABI is another issue. I'm unsure how to properly address >> ABI breakage -- bumping libc's .so version, or reversion all symbols >> that use something with time_t, or something else. If I can address >> it before the code freeze, it could be done for FreeBSD 11, which >> leaves about 6 hours from now. > For i386, the only practical option is going to be a new TARGET_ARCH and > likely ELF machine type. > > For powerpc, I'd be tempted to just break the ABI and leave a way to switch > it back for people who build products where the ABI change is an issue. > > -- Brooks I would agree with this. -Nathan From owner-freebsd-arch@freebsd.org Thu Jun 9 20:26:18 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 80529B700AB for ; Thu, 9 Jun 2016 20:26:18 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp9.server.rpi.edu (smtp9.server.rpi.edu [128.113.2.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "canit.localdomain", Issuer "canit.localdomain" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 55B3B1517; Thu, 9 Jun 2016 20:26:17 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp-auth3.server.rpi.edu (smtp-auth3.server.rpi.edu [128.113.2.233]) by smtp9.server.rpi.edu (8.14.4/8.14.4/Debian-8) with ESMTP id u59KMoh6022459 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jun 2016 16:22:50 -0400 Received: from smtp-auth3.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth3.server.rpi.edu (Postfix) with ESMTP id 6E46A5815A; Thu, 9 Jun 2016 16:22:50 -0400 (EDT) Received: from [128.113.24.47] (gilead-qc124.netel.rpi.edu [128.113.124.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drosih) by smtp-auth3.server.rpi.edu (Postfix) with ESMTPSA id 621D058156; Thu, 9 Jun 2016 16:22:50 -0400 (EDT) From: "Garance A Drosehn" To: "Justin Hibbits" Cc: freebsd-arch@freebsd.org Subject: Re: PowerPC 64-bit time_t Date: Thu, 09 Jun 2016 16:22:50 -0400 Message-ID: In-Reply-To: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: 0.00 () [Hold at 10.10] X-CanIt-Incident-Id: 02R4ImOqG X-CanIt-Geo: ip=128.113.124.17; country=US; region=New York; city=Troy; latitude=42.7495; longitude=-73.5951; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.229 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: Thu, 09 Jun 2016 20:26:18 -0000 On 9 Jun 2016, at 13:41, Justin Hibbits wrote: > At the devsummit earlier today I mentioned for FreeBSD 12 wanting > 64-bit time_t across the board. It was pointed out that the only ones > with 32-bit time_t are i386 and powerpc (32-bit). I've made the > changes necessary for at least kernel (world is still building right > now), but it's obviously an ABI and KBI incompatible change. > Addressing KBI is a nonissue, as that's expected to break at major > releases. ABI is another issue. I'm unsure how to properly address > ABI breakage -- bumping libc's .so version, or reversion all symbols > that use something with time_t, or something else. If I can address > it before the code freeze, it could be done for FreeBSD 11, which > leaves about 6 hours from now. > > Any thoughts? I don't know if it would help to look at the changes done back when sparc64 went to a 64-bit time_t. I did a lot of that work, but I'll have to admit I remember almost nothing about the changes. -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@freebsd.org Thu Jun 9 20:38:37 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 3647BB703FF for ; Thu, 9 Jun 2016 20:38:37 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 F369B1DD3 for ; Thu, 9 Jun 2016 20:38:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x232.google.com with SMTP id a5so47978029ita.1 for ; Thu, 09 Jun 2016 13:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:cc:message-id:from:to:in-reply-to:content-transfer-encoding :mime-version:subject:date:references; bh=gF9SbeJ6Zv3IpJyJlh+mkv9KT9RE3s38DBN8de0amS4=; b=dKfbL/aghMuJfdmpXE8mhsmxc7aFvZGDzpKbNhGbwCMIHcFNyYucmlu9SXQOVDI579 ZtkMSCmQtQPL8LKPS+PIgE4gp6HtmNeykaZTwaC13CZOotEL7lnB1mSRF/yk3koscPvK DuyL18TMdG97W5kVdsHwzZ+mNrUQzZ5CItY1z59QqsfLW8DVgPGPS1iIaySqR/EJC5W+ wezoyXa8RqbaPdSvopQqKVT/kiokVkqYThbEVIVaBCl8TeWnELY0c68+Nq7gS8zvqQ6e iitujdcTnJnD3SDT0aLJ0QPYxrp26iSDBHsG0bW07148myWMxZyYL3WE1FdXHkgy4ToY W0FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:cc:message-id:from:to:in-reply-to :content-transfer-encoding:mime-version:subject:date:references; bh=gF9SbeJ6Zv3IpJyJlh+mkv9KT9RE3s38DBN8de0amS4=; b=aInpS0kUoJmp3iHAqP3Agj+q9DN3TyQiG0OWshe0P6cNzzGKPl4wcfYBsdZ8SHmW0a 18yiS25H4HuN+PClsiIxgvsDDTTvli0dmYdYS/uIgyrAmppe3+3r9Kb2f+5ugh8S6xYE DdWkcQcboqkxp4lxjSjfvF3lVT9zoBjI9YWT3reFlrlx3mLFw/UQHpKgvTsOdurlbB7k LF4vqnoFGMpGZz741LVM3OrbLWv4hBla90VjvH0hu5XPhmq2Xh456sfj+gSe2hx887rb czCOdb45yeJ9J3RGECEJbJzVReMHn1dKHaY6ai5LKbe8n7iBafL+odDHEcHzeadijlAY KIKg== X-Gm-Message-State: ALyK8tIuw4LrYrY08oNwz/E/YCkw83waGqfooZu0l+U5qkqDZ86VCD0Z26kG92bT520ySQ== X-Received: by 10.36.68.88 with SMTP id o85mr20560070ita.39.1465504716453; Thu, 09 Jun 2016 13:38:36 -0700 (PDT) Received: from [10.65.211.198] ([137.122.64.8]) by smtp.gmail.com with ESMTPSA id u62sm14286065itd.10.2016.06.09.13.38.35 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 09 Jun 2016 13:38:36 -0700 (PDT) Sender: Justin Hibbits Cc: freebsd-arch@freebsd.org Message-Id: <51CA1453-0393-4D72-BAC6-053318B001E0@freebsd.org> From: Justin Hibbits To: Garance A Drosehn In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: PowerPC 64-bit time_t Date: Thu, 9 Jun 2016 16:38:34 -0400 References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> X-Mailer: Apple Mail (2.936) 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: Thu, 09 Jun 2016 20:38:37 -0000 On Jun 9, 2016, at 4:22 PM, Garance A Drosehn wrote: > On 9 Jun 2016, at 13:41, Justin Hibbits wrote: > >> At the devsummit earlier today I mentioned for FreeBSD 12 wanting >> 64-bit time_t across the board. It was pointed out that the only >> ones with 32-bit time_t are i386 and powerpc (32-bit). I've made >> the changes necessary for at least kernel (world is still building >> right now), but it's obviously an ABI and KBI incompatible change. >> Addressing KBI is a nonissue, as that's expected to break at major >> releases. ABI is another issue. I'm unsure how to properly >> address ABI breakage -- bumping libc's .so version, or reversion >> all symbols that use something with time_t, or something else. If >> I can address it before the code freeze, it could be done for >> FreeBSD 11, which leaves about 6 hours from now. >> >> Any thoughts? > > I don't know if it would help to look at the changes done back when > sparc64 went to a 64-bit time_t. I did a lot of that work, but I'll > have to admit I remember almost nothing about the changes. > > -- > Garance Alistair Drosehn = drosih@rpi.edu > Senior Systems Programmer or gad@FreeBSD.org > Rensselaer Polytechnic Institute; Troy, NY; USA Thanks. The UPDATING.64BIT file you created for the upgrade path for sparc64 is an excellent source for the headaches involved with source based upgrades from 32-bit time_t to 64-bit. - Justin From owner-freebsd-arch@freebsd.org Fri Jun 10 04:57: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 13916B702B9 for ; Fri, 10 Jun 2016 04:57:58 +0000 (UTC) (envelope-from peter@wemm.org) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9F5D1F97 for ; Fri, 10 Jun 2016 04:57:57 +0000 (UTC) (envelope-from peter@wemm.org) Received: from Peters-MacBook-Pro.local (unknown [137.122.64.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: peter) by smtp2.wemm.org (Postfix) with ESMTPSA id F100C44C for ; Thu, 9 Jun 2016 21:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1465534677; bh=tRDEeMP7s/7IA+EgTrfv8Gyrfg0utdUSmPW/H7Vm5IU=; h=Subject:To:References:From:Date:In-Reply-To; b=crZzU1H0KqkokcrEcrY7OOAdbJCF2Z2AdIi4ZmTv6VIZK+ZV+8rqU24/fCglv44/P x8pvQwA626jQyZaK04Fmy/KKERZBGwY/UaHFKLvtDFvTkzwTgXpf0jtWXkIRK0oUGk blnrqn1th5ygDjOnHKyFpHMzqtuMY3ZcYib6/VAk= Subject: Re: PowerPC 64-bit time_t To: freebsd-arch@freebsd.org References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> <20160609193128.GB34204@spindle.one-eyed-alien.net> From: Peter Wemm Message-ID: <575A48D3.3090008@wemm.org> Date: Fri, 10 Jun 2016 00:57:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20160609193128.GB34204@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 10 Jun 2016 04:57:58 -0000 On 6/9/16 3:31 PM, Brooks Davis wrote: > On Thu, Jun 09, 2016 at 01:41:52PM -0400, Justin Hibbits wrote: >> At the devsummit earlier today I mentioned for FreeBSD 12 wanting 64- >> bit time_t across the board. It was pointed out that the only ones >> with 32-bit time_t are i386 and powerpc (32-bit). I've made the >> changes necessary for at least kernel (world is still building right >> now), but it's obviously an ABI and KBI incompatible change. >> Addressing KBI is a nonissue, as that's expected to break at major >> releases. ABI is another issue. I'm unsure how to properly address >> ABI breakage -- bumping libc's .so version, or reversion all symbols >> that use something with time_t, or something else. If I can address >> it before the code freeze, it could be done for FreeBSD 11, which >> leaves about 6 hours from now. > > For i386, the only practical option is going to be a new TARGET_ARCH and > likely ELF machine type. I investigated this when I did 64 bit time_t on amd64 - the chances of getting this to work on i386 are ... problematic.. to say the least. A short summary of the issues for i386: * sparc64, amd64 and ia64 were "easy" because there was an actual register to implement it. Calling conventions plaster over vast quantities of sins and carelessness and make it Just Work by in spite of it. You forget a function prototype and it still works. i386 has to do it with "long long" which requires discipline. Miss a prototype and it falls flat. eg: if you miss the prototype for a function returning time_t the language defaults the return value to "int". On ia64, amd64 and sparc64, this is actually returned as a 64 bit value (native register) and it actually gets the full 64 bit value. For i386, this doesn't happen - you always get truncation. You won't find out until it actually matters. This problem will keep turning up forever. The top half will be returned in the %edx secondary return register and will be ignored. * classic 3rd party code used "long" and "time_t" interchangeably. We get away with this on ia64, amd64 and sparc64 just fine. This will also lead to truncation on i386 with 64 bit time_t when it matters. * Sloppy prototyping leads to stack misalignment on i386 with "long long". Arguments are rounded up to 32 bit alignment, so char/short/int/long confusion on i386 for function calling protocol mostly is repaired as a side effect. 'long long' doesn't get this treatment for function calls - any sloppiness will be punished with arguments being shifted. Unlike the truncation above, this is pretty quick to find. You won't have to wait 5-10 years for them to shake out. Most of the FreeBSD base tree was fixed for this during the Alpha era (which used "int" for time_t on a 64 bit platform because mktime() in libc wasn't 64 bit safe at all). However, when you go near ports and 3rd party code the situation is rather grim. The code out there is terrible. I maintain that while we got away with it for machines that the calling conventions masked the pain for sloppy and legacy programming, this is not the case for architectures like i386. The pain will never end. Do you want to be the one who has to explain why something like openssl isn't rejecting expired certificates because openssl happens to confuse long/time_t internally somewhere in the X509 validator? (Note: I'm not saying it is broken, but I don't have a hard time imagining that it could..). Also, don't forget all the compat_freebsd32 layers. You'll have to realign all the arguments because 'long long' is 32 bit aligned, and a 64 bit long (aka time_t) is 64 bit aligned. I'm sure it could be done for a science project, but I wouldn't want to go anywhere near it for something that would be relied upon. This would be a project that gives gifts that will keep on giving. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 From owner-freebsd-arch@freebsd.org Fri Jun 10 17:24:09 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 7A0C2AD9297 for ; Fri, 10 Jun 2016 17:24:09 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 420B4270D for ; Fri, 10 Jun 2016 17:24:08 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id BQA4bQagqN9d0BQA5bVYdk; Fri, 10 Jun 2016 11:24:02 -0600 X-Authority-Analysis: v=2.2 cv=QZUkhYTv c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=pD_ry4oyNxEA:10 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=I1WsqfqijMZbk78XKgMA:9 a=pxhY87DP9d2VeQe4joPk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id CBA0613751 for ; Fri, 10 Jun 2016 10:23:59 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id u5AHNx4U060934 for ; Fri, 10 Jun 2016 10:23:59 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201606101723.u5AHNx4U060934@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-arch@freebsd.org Subject: Illumos/OpenSolaris SMF to FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Jun 2016 10:23:59 -0700 X-CMAE-Envelope: MS4wfNgQJc8q0HMULTC4ARkOQaJOZvQEIhHEJv5icZ9WWunp3hrozO7qqKC9oQbYZkWlaDIJMyeIIR0cpTsMEGBFsIX4JIDRUrdMo04bZ2ESwPjrysSw4DSr CLlhd8QYCBfYnnOflbRKOmqcAN/TYzAfaoDSNVh/BnaNf8LtRKLLvBXFhHHnbWcqKa1T8xi3xyFiKQ== 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: Fri, 10 Jun 2016 17:24:09 -0000 Hi, What are people's thoughts about porting Illumos Service Management Facility (SMF) to FreeBSD? The Solaris SMF didn't replace their init(8), it's started by their init(8) through inittab -- we could use ttys or replace init. Like DTrace and ZFS, SMF is CDDL. Does that matter? -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Sat Jun 11 04:13:54 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 2720CAEF8E6 for ; Sat, 11 Jun 2016 04:13:54 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7A7E23D8 for ; Sat, 11 Jun 2016 04:13:53 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1465618432; bh=18eAU+fcQlNLnJD9s15TgkrMdj6mlFhKchbyrpg7A7g=; h=To:Cc:From:Subject:Date:From:Subject; b=VIRaqBvivt/S7y+9ilV/FTBV/PegwaVWcytAYSXlSJ1EBsDR+No3dLwQzT+U4EllFkzh9+KQw6X0BRsPZ+uaHKrR4Wpa3y40CrIW16GliepQP3Cs6HEcIbH55tYtfZKdG+Evd3TSnntTUwY5L4vuCXQqDFg/gxYBHU8mXtTLmGYxN9Q5/6CDbrhZk49gzXSixxV3JEb8wVNrbhz3h9LpDtg/YZdFc/eh3OJ50xpmV7Z59eLitVVb5F1cz23IlM6EzHWtAlujQXXDw6KNdsx2eIEebECOyRkar+7jPOlWwzfY4v0yA7j89BeAREzeJ/ytV5DQmcOQW6REond6GW8q/A== Received: from [98.139.215.143] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jun 2016 04:13:52 -0000 Received: from [98.139.211.200] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jun 2016 04:13:52 -0000 Received: from [127.0.0.1] by smtp209.mail.bf1.yahoo.com with NNFMP; 11 Jun 2016 04:13:52 -0000 X-Yahoo-Newman-Id: 700494.80691.bm@smtp209.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5U8i3QgVM1kKDSGTlEEAN23ksOa6AqS3yyGnp645X2Ddm_q GTIoI6W56AJhLHGzCWi.dk.2gzRlahHVvY8Z.tmDY6wglie.LIV7mrzCCyLP P2uiVtSJqZPmDcvJbZvoLjQieEFTWPZphRrgb_sRCNtwwnh2AKmZe_omVtu. 43_vXJPZ0I1qu48kUHAfjQXRJYt2X4ZTn_R_thP7F4TFZlBKWxin6IToMlYS YsLF.tscjjOarwB_XYj.TDyU9d0ToFCBnyFM9Tw_ToYc1SHfrCVKt6BCb5My 6CfAH4LlaMfCfdWsSVkUNpEnNTj7UpPvk_CrLl4E3HAuUtvdPFbEXwKbhpDy 9sIEvliS2PdwDwHPnPEbMFQPbT6kigrqOgDbjXoMJinQYvM2scFfZp0dlQQ3 S7HozRlQEHBEEyuJHFRhAq8m01YKVIq4N4XqYxWCLPh4HZUVqwY8.p3pNQ3L 2msL9tUJLpyf.8v83.tCHZBRJyvEc4rzkVbh4qXCZLKL4sPVCFfmOASDV1vn K2wLt3dlN.NhzF72PdiXzl_gSRtDktw3_ X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf To: FreeBSD-arch list From: Pedro Giffuni Subject: Re: Illumos/OpenSolaris SMF to FreeBSD Message-ID: Date: Fri, 10 Jun 2016 23:13:54 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 11 Jun 2016 04:13:54 -0000 Hi Cy; > Hi, > > What are people's thoughts about porting Illumos Service Management > Facility (SMF) to FreeBSD? The Solaris SMF didn't replace their init(8), > it's started by their init(8) through inittab -- we could use ttys or > replace init. > Is this something that could live in ports ... at least for a while? It appears there are many options and it's great to be able to choose, but I doubt we want to compromise right now on which, > Like DTrace and ZFS, SMF is CDDL. Does that matter? Yes, everything matters. As with all weak-copyleft, a requisite is that it cannot be made mandatory. Pedro. From owner-freebsd-arch@freebsd.org Sat Jun 11 05:13:30 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 20327AEF22B for ; Sat, 11 Jun 2016 05:13:30 +0000 (UTC) (envelope-from mark@heily.com) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 E7D412994 for ; Sat, 11 Jun 2016 05:13:29 +0000 (UTC) (envelope-from mark@heily.com) Received: by mail-io0-x236.google.com with SMTP id 5so82004195ioy.1 for ; Fri, 10 Jun 2016 22:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heily-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6vEDPnFYKQ8qy03mkslRHlx6ra8rLDzacY/CBjkYx1E=; b=ghm12LXd/fRhy4xl6CUgyU7dWgpqYbSmBm0qbRJ25X7kgEL7vD4kpRxqHgpVpMfpuY QEx5WTNr7a9/al4vu5EH61aME/2My72cgY7PU3FJh/njZwBJuMx1YeedUKZGYLA0GyM4 0SsFyR9OIQl2v+rEfl5HvMwBU4LeqJ6OtBMRbqgTd7RT/7snfmIfgmO2M1DizuOndSD3 shVGasmfE2RNGFbTsi7LtqNRf28h+sU23QAkxxu698GD8zx8qYSJ2L45GDUv4X8qMmo7 HGjbp+tjnW9RpYMgWgve2oKoM7fFSBJayzReSEMcJQuFgoSsflPJpFkWuwt+WS19SgG6 m1vw== 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:date :message-id:subject:from:to:cc; bh=6vEDPnFYKQ8qy03mkslRHlx6ra8rLDzacY/CBjkYx1E=; b=QvS/vEOV8YhF0k52KoGyTBa0TEIJRttY3/cyyBY3+4noT1LUGxmZ1aL/aPe9CMHg95 rhN3Hvqj8dU6zhJV0s5/GzWtR3FJbKatjz53u3G1p01zhGnZKMtQbgM2SG8YXEmBUz+x ghUWFToCXyzwYqvZrG4YdxHNF+KJAJpX91xdNVt5NrZV5t2Rlsm7ZMY0eH959yNdJFv2 9pHbe+wWqUgxwibIjmS+Y9Qgmr9gzdKSFGo3pxLqkDW830PfZr9p9r2y0iXqAEOs3nUK V7tGuVLxWdP27eeymxizLTVD3PfnWfnQ7rh8oAxT4WmYxlOdXgxpocrUQZFj3QMiIROo ewXg== X-Gm-Message-State: ALyK8tL3qoHxJRPA/UuatJhwF+yKP4tMCMQcz9kACpvtFVJKe3LIsfxGzigJn8b4rR2Ybc2OGvQwWGsXeGdZnA== MIME-Version: 1.0 X-Received: by 10.107.38.10 with SMTP id m10mr10134320iom.7.1465622009178; Fri, 10 Jun 2016 22:13:29 -0700 (PDT) Received: by 10.79.114.156 with HTTP; Fri, 10 Jun 2016 22:13:29 -0700 (PDT) X-Originating-IP: [137.122.64.52] In-Reply-To: References: Date: Sat, 11 Jun 2016 01:13:29 -0400 Message-ID: Subject: Re: Illumos/OpenSolaris SMF to FreeBSD From: Mark Heily To: Pedro Giffuni Cc: FreeBSD-arch list 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: Sat, 11 Jun 2016 05:13:30 -0000 On Sat, Jun 11, 2016 at 12:13 AM, Pedro Giffuni wrote: > Hi Cy; > > Hi, >> >> What are people's thoughts about porting Illumos Service Management >> Facility (SMF) to FreeBSD? The Solaris SMF didn't replace their init(8), >> it's started by their init(8) through inittab -- we could use ttys or >> replace init. >> >> > Is this something that could live in ports ... at least for a while? > It appears there are many options and it's great to be able to choose, > but I doubt we want to compromise right now on which, > > Full disclosure: I'm working on a competing project called jobd that is heavily influenced by MacOS launchd and Solaris SMF, while not sharing any source code with these earlier systems. I think it would be extremely challenging to port Solaris SMF to FreeBSD because of the number of dependencies on Solaris-specific kernel features and libraries. I took some time to investigate these dependencies, based on the contents of the /usr/srv/cmd/svc directory in Illumos: https://github.com/illumos/illumos-gate/tree/5a4ef21a18dfdc65328821a265582d03e85a97c9/usr/src/cmd/svc I grepped all the source code under that directory for the pattern '#include .*', and came up with a list of all of the system headers that SMF requires. The list is very large, and includes some major kernel features like doors, event ports, procfs, kstat, zones, privileges, and so on. The source code to SMF has been publicly available for eight years, yet no one has stepped forward to invest the time and effort to port it to a different OS. I don't see that situation changing any time soon. Where is the funding? Who are the commercial backers? How many full-time engineers will be dedicated to the porting effort? How many years are we willing to wait for the port to be completed? IMHO it would be better to borrow the best ideas from the other Unix init systems and implement them in jobd. It's simply not realistic to port the original SMF source code to FreeBSD. P.S. Here are is a partial list of the Solaris-specific facilities that would need to be ported to FreeBSD to get the Solaris SMF sources to compile. Event ports: https://blogs.oracle.com/barts/entry/entry_2_event_ports contract(4) filesystem http://docs.oracle.com/cd/E23823_01/html/816-5174/contract-4.html corectl(2): https://github.com/illumos/illumos-gate/blob/5a4ef21a18dfdc65328821a265582d03e85a97c9/usr/src/uts/common/syscall/corectl.c libgen: http://docs.oracle.com/cd/E23823_01/html/816-5173/libgen-3head.html libgrubmgmt: https://github.com/illumos/illumos-gate/tree/5a4ef21a18dfdc65328821a265582d03e85a97c9/usr/src/lib/libgrubmgmt libscf: http://docs.oracle.com/cd/E23824_01/html/821-1464/libscf-3lib.html libuutil: https://blogs.oracle.com/sch/entry/libuutil_and_designing_for_debuggability libumem: https://blogs.oracle.com/pnayak/entry/finding_memory_leaks_within_solaris libtecla: https://docs.oracle.com/cd/E19044-01/sol.containers/817-1592/z.config.ov-18/index.html libfmevent: https://docs.oracle.com/cd/E19455-01/805-7224/6j6q44cj5/index.html kstat kernel support: https://docs.oracle.com/cd/E23824_01/html/821-1478/kstat-9s.html libkstat: https://docs.oracle.com/cd/E19683-01/806-6543/overview-12/index.html librestart: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/librestart/common/librestart.h libsysevent: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libsysevent/libsysevent.c file tree walker libc functions: http://docs.oracle.com/cd/E19109-01/tsolaris7/805-8069/6j7j9vntn/index.html sys/modctl.h: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/modctl.h mnttab functions in sys/mnttab: http://www.manpages.spotlynx.com/solaris/man/getmntent.3C procfs: https://github.com/illumos/illumos-gate/blob/5a4ef21a18dfdc65328821a265582d03e85a97c9/usr/src/uts/common/sys/procfs.h privileges(5): http://docs.oracle.com/cd/E36784_01/html/E36883/privileges-5.html#REFMAN5privileges-5 doors: https://en.wikipedia.org/wiki/Doors_(computing) SAC port monitors: https://docs.oracle.com/cd/E19455-01/805-7224/6j6q44cj5/index.html statvfs: http://docs.oracle.com/cd/E23824_01/html/821-1463/statvfs-2.html uadmin(2) system call: https://illumos.org/man/2/uadmin Zones: https://github.com/illumos/illumos-gate/blob/master/usr/src/head/zone.h From owner-freebsd-arch@freebsd.org Sat Jun 11 21:15:54 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 611ECAF0E18 for ; Sat, 11 Jun 2016 21:15:54 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F0682A13; Sat, 11 Jun 2016 21:15:53 +0000 (UTC) (envelope-from cy.schubert@komquats.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with SMTP id BqFybZLFKN9d0BqFzbZuYc; Sat, 11 Jun 2016 15:15:52 -0600 X-Authority-Analysis: v=2.2 cv=QZUkhYTv c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=pD_ry4oyNxEA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=g0hI5vPJ-v-BAtpAV98A:9 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id A4F2713751; Sat, 11 Jun 2016 14:15:50 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id u5BLFmOL088454; Sat, 11 Jun 2016 14:15:48 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201606112115.u5BLFmOL088454@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Pedro Giffuni cc: FreeBSD-arch list , Cy Schubert Subject: Re: Illumos/OpenSolaris SMF to FreeBSD In-Reply-To: Message from Pedro Giffuni of "Fri, 10 Jun 2016 23:13:54 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Jun 2016 14:15:48 -0700 X-CMAE-Envelope: MS4wfHXsICOdP5ldn9/IKaDEy0zs/5v/Er7GX3k0jy4TnBtPsz7LovZGG8SaJ7H1U9OJ/+EltI3rRdsmC/ipsxlDuz0yJuHNYQYYRs5uMlcdSPNOD0fa3i4V fyf2ulLFoiDwkcRZ0aD48jGtlZ8k3bsZiWH1UImu3uFk6T9VnOnjSR3nzTN9LgI0c+hYioc5b31sBQSxSiCFI8cGejvraDg7N8g= 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: Sat, 11 Jun 2016 21:15:54 -0000 In message , Pedro Giffuni wr ites: > Hi Cy; > > > Hi, > > > > What are people's thoughts about porting Illumos Service Management > > Facility (SMF) to FreeBSD? The Solaris SMF didn't replace their init(8), > > it's started by their init(8) through inittab -- we could use ttys or > > replace init. > > > > Is this something that could live in ports ... at least for a while? > It appears there are many options and it's great to be able to choose, > but I doubt we want to compromise right now on which, > > > Like DTrace and ZFS, SMF is CDDL. Does that matter? > > Yes, everything matters. As with all weak-copyleft, a requisite is > that it cannot be made mandatory. I wasn't aware that this was an issue to some vendors. db@ and I discussed it very briefly on IRC. I suppose it could be made optional however that would mean every start-up script would need to be duplicated in both environments and that doesn't make any sense. As nice as it would be, it's probably not meant to be. Having said all that, I don't think that Apple's launchd was meant for servers or the enterprise, not to mention they closed-sourced it. We probably have to write our own. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-arch@freebsd.org Sat Jun 11 21:37:12 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 A054BAF00FC for ; Sat, 11 Jun 2016 21:37:12 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 82D61202E; Sat, 11 Jun 2016 21:37:12 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id EE1422AA4A5; Sat, 11 Jun 2016 15:36:33 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 6AF6C1CDE4; Sat, 11 Jun 2016 17:37:09 -0400 (EDT) Date: Sat, 11 Jun 2016 17:37:09 -0400 From: Diane Bruce To: Cy Schubert Cc: Pedro Giffuni , FreeBSD-arch list Subject: Re: Illumos/OpenSolaris SMF to FreeBSD Message-ID: <20160611213709.GA7314@night.db.net> References: <201606112115.u5BLFmOL088454@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201606112115.u5BLFmOL088454@slippy.cwsent.com> User-Agent: Mutt/1.6.1 (2016-04-27) 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: Sat, 11 Jun 2016 21:37:12 -0000 On Sat, Jun 11, 2016 at 02:15:48PM -0700, Cy Schubert wrote: > In message , Pedro > Giffuni wr > ites: > > Hi Cy; > > > > > Hi, > > > > > > What are people's thoughts about porting Illumos Service Management > > > Facility (SMF) to FreeBSD? The Solaris SMF didn't replace their init(8), > > > it's started by their init(8) through inittab -- we could use ttys or > > > replace init. > > > > > > > Is this something that could live in ports ... at least for a while? > > It appears there are many options and it's great to be able to choose, > > but I doubt we want to compromise right now on which, > > > > > Like DTrace and ZFS, SMF is CDDL. Does that matter? > > > > Yes, everything matters. As with all weak-copyleft, a requisite is > > that it cannot be made mandatory. > > I wasn't aware that this was an issue to some vendors. db@ and I discussed > it very briefly on IRC. I suppose it could be made optional however that > would mean every start-up script would need to be duplicated in both > environments and that doesn't make any sense. As nice as it would be, it's > probably not meant to be. bleh. how about an OPEN SMF ? ;) > > Having said all that, I don't think that Apple's launchd was meant for > servers or the enterprise, not to mention they closed-sourced it. We > probably have to write our own. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > > _______________________________________________ > 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" > -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arch@freebsd.org Sat Jun 11 21:44:09 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 C0216AF030A for ; Sat, 11 Jun 2016 21:44:09 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm45-vm1.bullet.mail.bf1.yahoo.com (nm45-vm1.bullet.mail.bf1.yahoo.com [216.109.115.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A4F62627 for ; Sat, 11 Jun 2016 21:44:09 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1465681442; bh=cwfOh+VUdZ+E6OeLqbPtAKKZXeCxifJjprhdeh1yVE0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=cEIQg1rfhIAMZfjfOu3li9W2rgP5teoOQlFIgTg/cd+RFI09VcclwVs1BM1cjk/Z5zHYS3Ecc/InpeGYm1/EwMuvf/WuGMAEVgh5pkmCsleSCvZRiAM3WqKNN+iU8zIS3psl1+KyodTactypzv03BMkPazIEJf/4kne28xM7dAajgZmesE0uV0YBcPcS4X8BReTaIvpjx68Eg5FC0c7PeD5C1PU3BsjMLn9GrXrUXzmO9cbAxZ2aBB50e+jPQC0AxZz6b219FETnLGjzb1nO91o4/RxjMStIEhwDrzLWH1Fwq3/KqDT4WkuKu+DN+vdq73nrLeYcd6sgLC7Tk4fisg== Received: from [66.196.81.172] by nm45.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jun 2016 21:44:02 -0000 Received: from [98.139.211.194] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jun 2016 21:44:02 -0000 Received: from [127.0.0.1] by smtp203.mail.bf1.yahoo.com with NNFMP; 11 Jun 2016 21:44:02 -0000 X-Yahoo-Newman-Id: 760682.30127.bm@smtp203.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5QvXtpQVM1k_BoMdF8XzAOm2gVX8.Nf2pTmHL_kPLWhiyu5 B0447Jg5HJ_17p7IwYfgMULB_85Npkap.3nwbkOLqKtq7ivYO.joWicf4t5T FFWVBi0KR18Kz9TBfyUiwNldiawvqjeUNva3xQG7JIvFSNCs.wySuGN8v1wn 5GZ80jVjhyZJtI0GUHrCXJB.Fcqv3_SBLYXPbdcfwhZJs5lp6kVqiqQna2hW Y4HxnYXkJGLeMijlOazda0a3Ip8fEtpvh1krVtTAOwRi6hVkEKvsfGG7oIFk uzqPiWslPHbWR0uTCD6Sn4GO2fNZ4ZM1RFym3_lxWt8Mundp7IJFVI6do1NF NhHn2YTTo2_Z1zCKBpCMyKHVEeP302plUam9U83V9BlEAY9ufUr6agyRNyTy dh1v4qClUNvDvBJbj1oSWP7QZJLTb2Ejv5tC_O8ymMTaZo9jVuQv4YMV9o1j RSBvuXeSKeG1OGiVuanRmxYQaHGejk6FjPNc81Vv7aSCZKeOXrqHDE6mn0.o HA9JI4OSGSqjoNzH9QqEWwFlSEHfk9mu. X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Illumos/OpenSolaris SMF to FreeBSD To: Cy Schubert References: <201606112115.u5BLFmOL088454@slippy.cwsent.com> Cc: FreeBSD-arch list From: Pedro Giffuni Message-ID: <5f424e4b-f6ea-c20f-e074-c52c50531728@FreeBSD.org> Date: Sat, 11 Jun 2016 16:44:04 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <201606112115.u5BLFmOL088454@slippy.cwsent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 11 Jun 2016 21:44:09 -0000 On 11/06/2016 16:15, Cy Schubert wrote: > In message , Pedro > Giffuni wr > ites: >> Hi Cy; >> >>> Hi, >>> >>> What are people's thoughts about porting Illumos Service Management >>> Facility (SMF) to FreeBSD? The Solaris SMF didn't replace their init(8), >>> it's started by their init(8) through inittab -- we could use ttys or >>> replace init. >>> >> Is this something that could live in ports ... at least for a while? >> It appears there are many options and it's great to be able to choose, >> but I doubt we want to compromise right now on which, >> >>> Like DTrace and ZFS, SMF is CDDL. Does that matter? >> Yes, everything matters. As with all weak-copyleft, a requisite is >> that it cannot be made mandatory. > I wasn't aware that this was an issue to some vendors. db@ and I discussed > it very briefly on IRC. I suppose it could be made optional however that > would mean every start-up script would need to be duplicated in both > environments and that doesn't make any sense. As nice as it would be, it's > probably not meant to be. It would be nice to have something compatible to Solaris but Mark Heily provided a complete list of showstoppers. I know libtecla is in ports and it would be nice to have something like doors but the list is sufficiently long that he port will not happen. > Having said all that, I don't think that Apple's launchd was meant for > servers or the enterprise, not to mention they closed-sourced it. We > probably have to write our own. > > Or we could just *fork* it: it is under a fine license so there is no need to rewrite everything. I personally don't have much interest in such a project though. I would be happy just by merging some more changes from OpenBSD's cron. Pedro. From owner-freebsd-arch@freebsd.org Sat Jun 11 21:49: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 3C5E0AF0366 for ; Sat, 11 Jun 2016 21:49:06 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) Received: from barracuda.ixsystems.com (barracuda.ixsystems.com [12.229.62.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.ixsystems.com", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C7F626FB for ; Sat, 11 Jun 2016 21:49:05 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) X-ASG-Debug-ID: 1465681744-08ca04114012e9d0001-RYubVt Received: from zimbra.ixsystems.com ([10.246.0.20]) by barracuda.ixsystems.com with ESMTP id e1dblCRtkbEb6kH6 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 11 Jun 2016 14:49:04 -0700 (PDT) X-Barracuda-Envelope-From: jkh@mail.turbofuzz.com X-Barracuda-RBL-Trusted-Forwarder: 10.246.0.20 X-ASG-Whitelist: Client Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id 703CBDC6A84; Sat, 11 Jun 2016 14:49:04 -0700 (PDT) Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id C5ebxfUI_gxA; Sat, 11 Jun 2016 14:49:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.ixsystems.com (Postfix) with ESMTP id 96A3DDC6B00; Sat, 11 Jun 2016 14:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at ixsystems.com Received: from zimbra.ixsystems.com ([127.0.0.1]) by localhost (zimbra.ixsystems.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BJITBX2KHiN1; Sat, 11 Jun 2016 14:49:03 -0700 (PDT) Received: from [172.20.0.38] (vpn.ixsystems.com [10.249.0.2]) by zimbra.ixsystems.com (Postfix) with ESMTPSA id 2D1AADC6AFF; Sat, 11 Jun 2016 14:49:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Illumos/OpenSolaris SMF to FreeBSD From: Jordan Hubbard X-ASG-Orig-Subj: Re: Illumos/OpenSolaris SMF to FreeBSD In-Reply-To: <201606112115.u5BLFmOL088454@slippy.cwsent.com> Date: Sat, 11 Jun 2016 14:49:02 -0700 Cc: Pedro Giffuni , FreeBSD-arch list Content-Transfer-Encoding: quoted-printable Message-Id: <5F7A1097-1B4F-4FA1-BC21-1648E9E5751A@mail.turbofuzz.com> References: <201606112115.u5BLFmOL088454@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: UNKNOWN[10.246.0.20] X-Barracuda-Start-Time: 1465681744 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://10.246.0.26:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ixsystems.com X-Barracuda-BRTS-Status: 1 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: Sat, 11 Jun 2016 21:49:06 -0000 > On Jun 11, 2016, at 2:15 PM, Cy Schubert = wrote: >=20 > Having said all that, I don't think that Apple's launchd was meant for=20= > servers or the enterprise, not to mention they closed-sourced it. We=20= > probably have to write our own. Neither of those things are entirely true, however. 1. launchd is agnostic as to workload - there=E2=80=99s nothing = particularly =E2=80=9Cconsumer-centric=E2=80=9D about its actual design = and it works perfectly well in OS X Server, though of course terms like = =E2=80=9CServer=E2=80=9D and =E2=80=9CEnterprise=E2=80=9D are also broad = enough that you can find both pro and con cases to support either = argument so I don=E2=80=99t know that it even makes sense to go there. 2. While it is true that the most recent versions of launchd (in = Mavericks / Yosemite) have not yet been released, you can start with = earlier versions and some might even argue that it makes more sense to = do so, as launchd has become somewhat more Apple-centric over time. We = had no problems porting the earlier versions of it to NextBSD, however, = and it=E2=80=99s running there just fine. It also has an Apache = license, just to circle back to the license question. There are other reasons that one may or may not wish to use launchd as a = service management framework, and I=E2=80=99m certainly not going to = resurrect the old arguments with Mark H. over that (been there, done = that, no point in reprising them), but neither of those two would make = the top-ten list. - Jordan