From owner-freebsd-hackers@freebsd.org Sat Mar 3 15:25:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFF91F44AE1 for ; Sat, 3 Mar 2018 15:25:39 +0000 (UTC) (envelope-from debdrup@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 15B4185FEA for ; Sat, 3 Mar 2018 15:25:39 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id i80so17375057lfg.5 for ; Sat, 03 Mar 2018 07:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vM1kRjpol3JLI8xh5j2JZM9xfiEMlXgEfkbwbE+7Cl0=; b=MIGhCqQO5apKbJC/qnPyjnYbe8JN8qIizdyW5pNJpBKoo92zDVe6h7S+bUdtmlaaMw PsEFUexIpyyIdkQ0LOCX52H/+bdEAqoA9JVvo407S9yXkAnFjgN+C/A6H6e0KC9dKo+9 kOXgtSLjSIF9m9RhvxOprP3xtzCI2+HwHTIZeqslLuFjGFwJW4Gp0UfhH6qNOUEAaAZN QxFVU9bF4w6a5EtrII3npUp2zyqkoXclmgfrJoKoGBfwLk8/4DA99R98/pHQ9RvjxVQi 1PHanbhtm+KtACOGs5CBvUAas0FC6BpSYu6lUp3clYcpIBNMvwvSeAMkLur8GZuecqpk 2PqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vM1kRjpol3JLI8xh5j2JZM9xfiEMlXgEfkbwbE+7Cl0=; b=NMNWyGsaGyOjkRng6iQB8Djs+0qGSQ0Lzuby1uqHmiq4dmICuevfQxRqreEEUpbhEe ueciNO+ZyzcOww7RYznU1nex6NbQ1pRP/cgjrxcxI+zBlFO/7qMwlVvhQtMO7dDAxYom eagDP/p59v+/R8McHWLwFrGGRgFAXTG34zScoZo4zx7di4mtZzsWvEsAVe2nihLzT4yg pSGvyd7Jm77KP9VpMJyOq1eBQhenKQH7CcPfcYTSB+7QFQDTbuOvGosHEHup8e+SbAS8 Xvd0QEHQHUDf4V38vqQFl9cNdj9hmXDFIn2JTPL6vR74ulga2hhTm+K4F1m6OkkRk5BR 92AQ== X-Gm-Message-State: APf1xPDxhDmpWZDwPETSthkWkCJ+7OS3x3z5NuFOzukIoSvydxqmpcoZ /CJ5AfMktpCR0LQUKocpT5ax0ZDYkYfB3RDBuz103wfI X-Google-Smtp-Source: AG47ELsIGPrEspWh4k33GadPywrFLdLkhCG7RVRhQqwLOWNqPFgF8+zEyd0SBVmq3CcC2PU8nVytrydCWlEfZGhRDb4= X-Received: by 10.46.44.6 with SMTP id s6mr6581129ljs.111.1520090737438; Sat, 03 Mar 2018 07:25:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.112.21 with HTTP; Sat, 3 Mar 2018 07:25:36 -0800 (PST) From: "D. Ebdrup" Date: Sat, 3 Mar 2018 16:25:36 +0100 Message-ID: Subject: Re: OpenRC 0.35 for FreeBSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sun, 04 Mar 2018 05:21:17 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 15:25:39 -0000 On Fri, Mar 2, 2018 at 3:28 AM, Alan Somers wrote: > On Fri, Mar 2, 2018 at 1:37 AM, Lars Engels wrote: > > > On Thu, Mar 01, 2018 at 08:02:23PM -0500, Joe Maloney wrote: > > > Hello hackers, > > > I have been working on a single diff version of OpenRC for FreeBSD: > > > > > > https://github.com/pkgdemon/freebsd/commit/b6885cd533c848a1b4f3582f48e40c883669b35c > > > > Thanks for your work! > > > > > > > > Why OpenRC? The licensing is right, and it's a way of adding modern > > > features to service management without reinventing the wheel. That's > > > my sales pitch. > > > > Hm, that does not convince me. FreeBSD's rc is also BSD licensed and did > > not reinvent any wheel. > > Could you maybe give some comparison between OpenRC and our rc? What > > does OpenRC better? > > > > Thanks! > > > > Lars > > > Parallel startup, mainly. This is absolutely not intended to in any way take away from the work that you have done and I don't expect you to answer, but I have to admit that I'm a bit worried about OpenRC since one of the main things it does better still appears to have a rather big and unsolved bug in the form of [1], that has been open since late 2011 according to [2]. And just to make it perfectly clear, I'm not saying that it's an unsolvable problem, but I do think it's one that needs to be solved before OpenRC can be imported. Mind you, I would love to have parallel service start-up - especially for machines with a lot of jails (for example, for non-dependant service separation) that are currently started sequencially, so I think it's fantastic work you've already done, and I definitely encourage you to work on it. [1] https://github.com/OpenRC/openrc/pull/12 [2] https://bugs.gentoo.org/show_bug.cgi?id=391945 Daniel Ebdrup aka. D. Ebdrup. From owner-freebsd-hackers@freebsd.org Sun Mar 4 05:41:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C4A5F3697B for ; Sun, 4 Mar 2018 05:41:54 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) (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 CCE4C6A89C for ; Sun, 4 Mar 2018 05:41:53 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f181.google.com with SMTP id g21so14652933ioj.5 for ; Sat, 03 Mar 2018 21:41:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=5i5bHtL8zqAh962iojPLHsrIiGCgMDosbAQ26K0YfgQ=; b=gEp/nvDtFCtTRT7xLolv/c8EtcwRaakEbhRmZZGfvjvMe3/zBloPYK7BWp3PJ/GuBX /c+7w9JOjqncDyDDGWEPKPv8k2OuGF7uFPWJidznd6aNx1czYOlIJK2Ev7k0iNJpswiP /dCFO5jvS04h76cbiYZZL0VovT6fKuen0ul06/OgZcqFkG/Zc5gUrJagalAEjeTJeDYk Aej12GWK0eH1X8QLIqWuNXRa2YbmRkrNBn640Wio9wEuF35mdap1sQZTytXhG9J3M6tb 3zUhFnkMc2HZ6nYfUNEQuN94ku6b4KgqKA/ceIBatHYHXQT+k1qMOHXzb/jpe+hD/3in /vrQ== X-Gm-Message-State: AElRT7EAz93oZLmeqqkTuVjmFwnaAB28p6xy4i7Uk0oqJz3nSK0emz3t TPXnYp1a6YJPgld9VxRvLtIgUuQB X-Google-Smtp-Source: AG47ELvPSsn6aojEEAws5InkpcbWcBG+kQPNFFb3A/xiR/8+VlS3k9GLpUfQB8ZHCraauFQoZBmTeg== X-Received: by 10.107.27.138 with SMTP id b132mr12557663iob.205.1520142107265; Sat, 03 Mar 2018 21:41:47 -0800 (PST) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id f193sm2847149ita.27.2018.03.03.21.41.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Mar 2018 21:41:47 -0800 (PST) Received: by mail-io0-f171.google.com with SMTP id u84so14656584iod.9 for ; Sat, 03 Mar 2018 21:41:47 -0800 (PST) X-Received: by 10.107.222.10 with SMTP id v10mr13120084iog.267.1520142107047; Sat, 03 Mar 2018 21:41:47 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Sat, 3 Mar 2018 21:41:46 -0800 (PST) In-Reply-To: References: From: Conrad Meyer Date: Sat, 3 Mar 2018 21:41:46 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: OpenRC 0.35 for FreeBSD To: Gleb Popov <6yearold@gmail.com> Cc: freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 05:41:54 -0000 On Fri, Mar 2, 2018 at 7:39 AM, Gleb Popov <6yearold@gmail.com> wrote: > I've been seeing nosh release announcements for a long time and was > thinking that this is what is going to replace current rc. Am I wrong? You're right that Jonathan does repeatedly spam the FreeBSD mailing lists with nosh announcements, but you're incorrect that there is any interest in adopting it as an rc replacement. IMO it's a non-starter for a number of reasons and I haven't heard real interest in it from anyone (except the author, of course). Best, Conrad From owner-freebsd-hackers@freebsd.org Sun Mar 4 11:53:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8750AF2B87D for ; Sun, 4 Mar 2018 11:53:00 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 303227780A; Sun, 4 Mar 2018 11:53:00 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) Received: from [192.168.19.1] (unknown [127.0.1.132]) by freefall.freebsd.org (Postfix) with ESMTP id B46601E5B6; Sun, 4 Mar 2018 11:52:59 +0000 (UTC) (envelope-from jonathan@FreeBSD.org) From: "Jonathan Anderson" To: "Conrad Meyer" Cc: "Gleb Popov" <6yearold@gmail.com>, freebsd-hackers Subject: Re: OpenRC 0.35 for FreeBSD Date: Sun, 04 Mar 2018 08:22:58 -0330 X-Mailer: MailMate (1.10r5443) Message-ID: <60EAAA41-4CB1-4043-A450-530B6E565FEB@FreeBSD.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 11:53:00 -0000 On 4 Mar 2018, at 2:11, Conrad Meyer wrote: > [...] IMO [nosh is] a non-starter for a number of reasons [...] Hi Conrad, Could you elaborate on those reasons? I'd like to understand the pros and cons of the various options. Jon -- Jonathan Anderson jonathan@FreeBSD.org From owner-freebsd-hackers@freebsd.org Sat Mar 3 17:16:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95C54F2AC20 for ; Sat, 3 Mar 2018 17:16:44 +0000 (UTC) (envelope-from robert.watson@cl.cam.ac.uk) Received: from cyrus.watson.org (cyrus.watson.org [204.107.128.30]) by mx1.freebsd.org (Postfix) with ESMTP id 462766BFCF; Sat, 3 Mar 2018 17:16:44 +0000 (UTC) (envelope-from robert.watson@cl.cam.ac.uk) Received: from [10.0.1.23] (host109-151-50-63.range109-151.btcentralplus.com [109.151.50.63]) by cyrus.watson.org (Postfix) with ESMTPSA id 2C7EFA2C4A; Sat, 3 Mar 2018 17:16:43 +0000 (UTC) From: "Robert N. M. Watson" Message-Id: <6E83EC9C-56C5-40E7-AED0-2692A15F7FD3@cl.cam.ac.uk> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [capsicum] unlinkfd Date: Sat, 3 Mar 2018 17:16:38 +0000 In-Reply-To: Cc: Alexander Richardson , "" , "freebsd-hackers@freebsd.org" To: Alan Somers References: <20180302183514.GA99279@x-wing> <17DE0BFF-42A2-4CD7-B09C-ABA2606C4041@cl.cam.ac.uk> X-Mailer: Apple Mail (2.3445.5.20) X-Mailman-Approved-At: Sun, 04 Mar 2018 11:58:29 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 17:16:44 -0000 New _check() variants of the unlinkat(2) and rmdirat(2) system calls = might do the trick -- e.g., int unlinkat_check(dirfd, name, checkfd); int rmdirat_check(dirfd, name, checkfd); The calls would succeed only if 'name' refers to the filesystem object = passed via checkfd. This would retain UNIX-style directory behaviour but = allows an atomic check that the object is as expected. Of course, what you do about it if it turns out the check fails is = another question... Better not to have a name at all, hence = shm_open(SHM_ANON, ...) -- although just for file objects, and not = directory hierarchies. Robert > On 3 Mar 2018, at 15:29, Alan Somers wrote: >=20 > In fact, FreeBSD has that same unlinkat(2) system call. But it = doesn't solve Mariusz's problem. He's concerned about race conditions. = With either unlink(2) or unlinkat(2), there's no way to ensure that the = directory entry you remove is for the file you think it is. Because = after reading/writing a file and before unlinking it, some other = processes could've unlinked it and created a new one with the same name. = It's this race condition that Mariuz seeks to solve with unlinkfd. > -Alan >=20 > On Sat, Mar 3, 2018 at 5:46 AM, Alexander Richardson = > wrote: > Linux has a unlinkat() system call = (https://linux.die.net/man/2/unlinkat = ) > but it doesn't seem to have a flag that lets you unlink the fd itself. > Possibly pathname =3D=3D NULL and AT_EMPTY_PATH could mean unlink the = fd but I > haven't tried whether that works. > It also has a AT_REMOVEDIR flag to make it function as rmdirat(). >=20 > On 3 March 2018 at 10:41, Robert N. M. Watson = > > wrote: >=20 > > FWIW, this is part of why we introduced anonymous POSIX shared = memory > > objects with Capsicum in FreeBSD -- we allow shm_open(2) to be = passed a > > SHM_ANON special name, which causes the creation of a swap-backed, = mappable > > file-like object that can have I/O, memory mapping, etc, performed = on it .. > > but never has any persistent state across reboots even in the event = of a > > crash. > > > > With Capsicum you can then refine a file descriptor to the otherwise > > writable object to be read-only for the purposes of delegation. = There is > > not, however, a mechanism to "freeze" the state of the object = causing other > > outstanding writable descriptors to become read-only -- certainly = something > > could be added, but some care regarding VM semantics would be = required -- > > in particular, so that faults could not be experienced as a result = of an > > memory store performed before the "freeze" but issued to VFS only = later. > > > > I certainly have no objection to an unlinkat(2) system call -- it's > > unfortunate that a full suite of the at(2) APIs wasn't introduced in = the > > first place. It would be worth checking that no one else (e.g., = Solaris, > > Mac OS X, Linux) hasn't already added an unlinkat(2) that we can = match API > > semantics for. I think I take the view that for truly anonymous = objects, > > shm_open(2) without a name (or the Linux equiv) is the right thing = -- and > > hence unlinkat(2) is for more conventional use cases where the final > > pathname element is known. > > > > On directories: There, I find myself falling back on a Casper-like > > service, since GC'ing a single anonymous memory object is = straightforward, > > but GC'ing a directory hierarchy is a more messy business. > > > > Robert > > > > > On 3 Mar 2018, at 09:53, Justin Cormack = > > > wrote: > > > > > > I think it would make sense to have an unlinkfd() that unlinks the = file > > from > > > everywhere, so it does not need a name to be specified. This might = be > > > hard to implement. > > > > > > For temporary files, I really like Linux memfd_create(2) that = opens an > > anonymous > > > file without a name. This semantics is really useful. (Linux memfd = also > > has > > > additional options for sealing the file fo make it immutable which = are > > very > > > useful for safely passing files between processes.) Having a way = to make > > > unnamed temporary files solves a lot of deletion issues as the = file > > > never needs to > > > be unlinked. > > > > > > > > > On 2 March 2018 at 18:35, Mariusz Zaborski > wrote: > > >> Hello, > > >> > > >> Today I would like to propose a new syscall called unlinkfd(2) = which > > came up > > >> during a discussion with Ed Maste. > > >> > > >> Currently in UNIX we can=E2=80=99t remove files safely. If we = will try to do so > > we > > >> always end up in a race condition. For example when we open a = file, and > > check > > >> it with fstat, etc. then we want to unlink(2) it=E2=80=A6 but the = file we are > > trying to > > >> unlink could be a different one than the one we were fstating = just a > > moment ago. > > >> > > >> Another reason of implementing unlinkfd(2) came to us when we = were > > trying > > >> to sandbox some applications like: uudecode/b64decode or bspatch. = It > > occured > > >> to us that we don=E2=80=99t have a good way of removing single = files. Of course > > we can > > >> try to determine in which directory we are in, and then open this > > directory and > > >> remove a single file. > > >> > > >> It looks even more bizarre if we would think about a program = which > > operates on > > >> multiple files. If we would analyze a situation with two totally > > different > > >> directories like `/tmp` and `/home/oshogbo` we would end up with = pre > > opening > > >> a root directory or keeping as many directories as we are working = on > > open. > > >> All of that effort only to remove two files. This make it totally > > impractical! > > >> > > >> I think that opening directories also presents some wider attack = vector > > because > > >> we are keeping a single descriptor to a directory only to remove = one > > file. > > >> Unfortunately this means that an attacker can remove all files in = that > > directory. > > >> > > >> I proposed this as well on the last Capsicum call. There was a > > suggestion that > > >> instead of doing a single syscall maybe we should have a Casper = service > > that > > >> will allow us to remove files. Another idea was that we should = perhaps > > redesign > > >> programs to create some subdirs work on the subdirs and then = remove all > > files in > > >> this subdir. I don=E2=80=99t feel that creating a Casper service = is a good idea > > because > > >> we still have exactly the same issue of race condition. In my = opinion > > creating > > >> subdirs is also a problem for us. > > >> > > >> First we would need to redesign some of our tools and I think we = should > > >> simplyfiy capsicumizition of the process instead of making it = harder. > > >> > > >> Secondly we can create a temporary subdirectory but what will = remove it? > > >> We are going back to having a fd to directory in which we just = created > > a subdir. > > >> Another way would be to have Casper service which would remove a > > directory but > > >> with the risk of RC. > > >> > > >> In conclusion, I think we need syscall like unlinkfd(2), which = turn out > > taht it > > >> is easy to implement. The only downside of this implementation is = that > > we not > > >> only need to provide a fd but also a path file. This is because = inodes > > nor > > >> vnodes don=E2=80=99t contain filenames. We are comparing vnodes = of the fd and > > the given > > >> path, if they are exactly the same we remove a file. In the = syscall we > > are using > > >> a fd so there is no Ambient Authority because we are proving that = we > > already > > >> have access to that file. Thanks to that the syscall can be = safely used > > with > > >> Caspsicum. I have already discussed this with some people and = they said > > >> `Hey I already had that idea a while ago=E2=80=A6` so let=E2=80=99s= do something with > > that idea! > > >> If you are intereted in patch you can find it here: > > >> https://reviews.freebsd.org/D14567 = > > >> > > >> Thanks, > > >> -- > > >> Mariusz Zaborski > > >> oshogbo//vx | http://oshogbo.vexillium.org = > > >> FreeBSD commiter | https://freebsd.org = > > >> Software developer | http://wheelsystems.com = > > >> If it's not broken, let's fix it till it is!!1 > > > > > > > > > > _______________________________________________ > freebsd-hackers@freebsd.org = mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers = > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org = " >=20 From owner-freebsd-hackers@freebsd.org Sun Mar 4 14:41:55 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45836F391BA for ; Sun, 4 Mar 2018 14:41:55 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E19787D419; Sun, 4 Mar 2018 14:41:54 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 1296A1EC; Sun, 4 Mar 2018 08:41:53 -0600 (CST) Date: Sun, 4 Mar 2018 08:41:52 -0600 From: Mark Linimon To: Conrad Meyer Cc: Gleb Popov <6yearold@gmail.com>, freebsd-hackers Subject: Re: OpenRC 0.35 for FreeBSD Message-ID: <20180304144151.GA28885@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Sun, 04 Mar 2018 16:36:26 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 14:41:55 -0000 On Sat, Mar 03, 2018 at 09:41:46PM -0800, Conrad Meyer wrote: > You're right that Jonathan does repeatedly spam the FreeBSD mailing > lists with nosh announcements I agree that he's promoting his work, but don't quite agree that it rises to the level of "spam". No, I don't know its technical merits/demerits. mcl From owner-freebsd-hackers@freebsd.org Sun Mar 4 17:12:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 306F6F44CA8 for ; Sun, 4 Mar 2018 17:12:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 AFF5A840CC for ; Sun, 4 Mar 2018 17:12:58 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 395f387e-1fcf-11e8-bb8e-b35b57339d60 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 395f387e-1fcf-11e8-bb8e-b35b57339d60; Sun, 04 Mar 2018 17:12:32 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w24HCtG9093279; Sun, 4 Mar 2018 10:12:55 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1520183575.23690.31.camel@freebsd.org> Subject: Re: OpenRC 0.35 for FreeBSD From: Ian Lepore To: Mark Linimon , Conrad Meyer Cc: freebsd-hackers , Gleb Popov <6yearold@gmail.com> Date: Sun, 04 Mar 2018 10:12:55 -0700 In-Reply-To: <20180304144151.GA28885@lonesome.com> References: <20180304144151.GA28885@lonesome.com> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2018 17:12:59 -0000 On Sun, 2018-03-04 at 08:41 -0600, Mark Linimon wrote: > On Sat, Mar 03, 2018 at 09:41:46PM -0800, Conrad Meyer wrote: > > > > You're right that Jonathan does repeatedly spam the FreeBSD mailing > > lists with nosh announcements > I agree that he's promoting his work, but don't quite agree that it > rises to the level of "spam". > > No, I don't know its technical merits/demerits. > > mcl > It may not be as annoying and off-topic as contact-list or fake-viagra offerings, but when you compare it to all the other advertising we tolerate on these lists (absolutely none at all), I've always considered it to be spam, and wondered why only one person/organization appears to be allowed to do it. -- Ian From owner-freebsd-hackers@freebsd.org Mon Mar 5 15:55:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C04A8F3A405 for ; Mon, 5 Mar 2018 15:55:54 +0000 (UTC) (envelope-from BATV+99cf327d66dc6ede388e+5307+infradead.org+hch@bombadil.srs.infradead.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (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 5F3FD7FA46; Mon, 5 Mar 2018 15:55:53 +0000 (UTC) (envelope-from BATV+99cf327d66dc6ede388e+5307+infradead.org+hch@bombadil.srs.infradead.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rXR73tCXi5egL7SJVwb7D9y113ujI1y+sseElNxi5UA=; b=tlWiFqCWztQwaqGLtuQUhMxrH MGRzE85Kx0krt5tFLyvji48MqzuDEyx0QSvIBc0TIQ+bkH0xNbQwIbN/nJRiAGkcQTPrXwEQKtLnO s7WxgB28qJB6b0LiFYQbw6hQlmQz6eVPuF5Wuf58TdOJctqsEbbztavqxIZHvFr4jQS/LmplwGqJo A59M7oNpvqqM+YbAErlHXUHwEeWkoL71KdKr/oaP46KRa83dW+EuSKjSXElCm1WQKp2X5WAY85p8r 7TmHFiGGH21jTEA19Yb2bBFbGXQJER9XTJbKfp4jj0QpGkKRVkWmvgBMNr4PNA+Cm1ZnSmvfLKfCi S6rcbCvKg==; Received: from hch by bombadil.infradead.org with local (Exim 4.89 #1 (Red Hat Linux)) id 1essSt-0008NZ-4S; Mon, 05 Mar 2018 15:55:51 +0000 Date: Mon, 5 Mar 2018 07:55:50 -0800 From: Christoph Hellwig To: "Robert N. M. Watson" Cc: Justin Cormack , "" , freebsd-hackers@freebsd.org, Mariusz Zaborski Subject: Re: [capsicum] unlinkfd Message-ID: <20180305155550.GA22789@infradead.org> References: <20180302183514.GA99279@x-wing> <17DE0BFF-42A2-4CD7-B09C-ABA2606C4041@cl.cam.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17DE0BFF-42A2-4CD7-B09C-ABA2606C4041@cl.cam.ac.uk> User-Agent: Mutt/1.9.2 (2017-12-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 15:55:55 -0000 With my Linux hat I'd much prefer using the AT_EMPTY_PATH flag that Linux already supports for a few *at calls to operate on the dirfd fd. But it seems like neither FreeBSD nor anyone else picked up that flag, so it might be a bit of a hard sell. FreeBSD bugzilla related to AT_EMPTY_PATH and the lack of it for unlinkat even in Linux: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197778 Linux bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93441 If you are interested in bringing this to FreeBSD that might be reason enough for me into looking into a Linux implementation as well. From owner-freebsd-hackers@freebsd.org Mon Mar 5 16:15:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CA80F3BF1E for ; Mon, 5 Mar 2018 16:15:57 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 E4C5580BB9; Mon, 5 Mar 2018 16:15:56 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w25GF8w4082407 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Mar 2018 18:15:12 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w25GF8w4082407 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w25GF8rr082406; Mon, 5 Mar 2018 18:15:08 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Mon, 5 Mar 2018 18:15:08 +0200 From: Konstantin Belousov To: Christoph Hellwig Cc: "Robert N. M. Watson" , "" , Mariusz Zaborski , Justin Cormack , freebsd-hackers@freebsd.org Subject: Re: [capsicum] unlinkfd Message-ID: <20180305161508.GE76926@kib.kiev.ua> References: <20180302183514.GA99279@x-wing> <17DE0BFF-42A2-4CD7-B09C-ABA2606C4041@cl.cam.ac.uk> <20180305155550.GA22789@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180305155550.GA22789@infradead.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 16:15:57 -0000 On Mon, Mar 05, 2018 at 07:55:50AM -0800, Christoph Hellwig wrote: > With my Linux hat I'd much prefer using the AT_EMPTY_PATH flag that > Linux already supports for a few *at calls to operate on the dirfd > fd. But it seems like neither FreeBSD nor anyone else picked up that > flag, so it might be a bit of a hard sell. > > FreeBSD bugzilla related to AT_EMPTY_PATH and the lack of it for > unlinkat even in Linux: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197778 > > Linux bugzilla: > > https://bugzilla.kernel.org/show_bug.cgi?id=93441 > > If you are interested in bringing this to FreeBSD that might be reason > enough for me into looking into a Linux implementation as well. It is not clear from the FreeBSD PR, how unlinkat() is supposed to work. Do you mean that unlinkat(AT_EMPTY_PATH) removes the name entry for given fd, which was used for open(2) ? If yes, this is not possible to implement in the current FreeBSD VFS. Also, does linkat(AT_EMPTY_PATH) supposed to link the inode referenced only by the file descriptor ? I believe this feature is objected to. From owner-freebsd-hackers@freebsd.org Mon Mar 5 18:42:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE47AF465A7 for ; Mon, 5 Mar 2018 18:42:35 +0000 (UTC) (envelope-from BATV+99cf327d66dc6ede388e+5307+infradead.org+hch@bombadil.srs.infradead.org) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) (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 56D176839F; Mon, 5 Mar 2018 18:42:35 +0000 (UTC) (envelope-from BATV+99cf327d66dc6ede388e+5307+infradead.org+hch@bombadil.srs.infradead.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q5BiZcZ9L/SISn4w80XuJXKVlLEHiDKHBvn5qgJWrFQ=; b=s6/oNNCnb6a3FkMQSVHye1Ag9 tMD25oJ1sgoakLtyo/lAJRj/vdGJ6c2ky11pjDnV+UsZD1fu+aDffzPL/wust/qrjR853VXvdySBe Dp9/x8LHdx9d14tduI/CQx8dCxYIdqGoKaZ99YhtiF3d7XXKWawY+RfgY3CRioo4yBbQo97EP8WaF RidDeP8GOq58nsiHzR0AEmiJsQkUD/sT2TnVMsuUJw/DHunGi99Smx7JcOaIetTkclYwzpcCGI2aI fwH29e5adTdzuw2fpMEQZo7FqvOnAcSFPTMF5KFuseyMyskWFF2bQN8fvmqTbw2LIdtEHbv0CTy2d EzGcjCTUA==; Received: from hch by bombadil.infradead.org with local (Exim 4.89 #1 (Red Hat Linux)) id 1esv4D-00057S-OT; Mon, 05 Mar 2018 18:42:33 +0000 Date: Mon, 5 Mar 2018 10:42:33 -0800 From: Christoph Hellwig To: Konstantin Belousov Cc: Christoph Hellwig , "Robert N. M. Watson" , "" , Mariusz Zaborski , Justin Cormack , freebsd-hackers@freebsd.org Subject: Re: [capsicum] unlinkfd Message-ID: <20180305184233.GA11236@infradead.org> References: <20180302183514.GA99279@x-wing> <17DE0BFF-42A2-4CD7-B09C-ABA2606C4041@cl.cam.ac.uk> <20180305155550.GA22789@infradead.org> <20180305161508.GE76926@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180305161508.GE76926@kib.kiev.ua> User-Agent: Mutt/1.9.2 (2017-12-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2018 18:42:35 -0000 On Mon, Mar 05, 2018 at 06:15:08PM +0200, Konstantin Belousov wrote: > It is not clear from the FreeBSD PR, how unlinkat() is supposed to work. > Do you mean that unlinkat(AT_EMPTY_PATH) removes the name entry for > given fd, which was used for open(2) ? It removes the current name for the open fd, including tracking renames that might have happened since open. > If yes, this is not possible to > implement in the current FreeBSD VFS. > > Also, does linkat(AT_EMPTY_PATH) supposed to link the inode referenced > only by the file descriptor ? I believe this feature is objected to. linkat(..., AT_EMPTY_PATH) in Linux creates a new link to inode reference by the fd. It is a privileged operation, and requires the inode to already have a non-zero link count, or be opened using the Linux-specific O_TMPFILE flag, which creates and open by unlinked file. From owner-freebsd-hackers@freebsd.org Tue Mar 6 07:27:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4292CF3991C for ; Tue, 6 Mar 2018 07:27:36 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "david.siemens.de", Issuer "Siemens Issuing CA Internet Server 2017" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCE3387004; Tue, 6 Mar 2018 07:27:35 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id w267RRMM016999 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Mar 2018 08:27:27 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.15.2/8.15.2) with ESMTP id w267RRe8017019; Tue, 6 Mar 2018 08:27:27 +0100 Received: (from user@localhost) by curry.mchp.siemens.de (8.15.2/8.15.2) id w267RRNH024137; Date: Tue, 6 Mar 2018 08:27:27 +0100 From: Andre Albsmeier To: Daniel Eischen Cc: Andre Albsmeier , freebsd-hackers@FreeBSD.org Subject: Re: Adding support for MosChip 9912 PCIe (serial/parallel) cards Message-ID: <20180306072727.GA86364@bali> References: <20180302061852.GA7887@bali> <20180303064400.GA27337@bali> <20180303184359.GA29745@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 07:27:36 -0000 On Sat, 03-Mar-2018 at 14:41:58 -0500, Daniel Eischen wrote: > On Sat, 3 Mar 2018, Andre Albsmeier wrote: > > > On Sat, 03-Mar-2018 at 10:53:20 -0500, Daniel Eischen wrote: > >> On Sat, 3 Mar 2018, Andre Albsmeier wrote: > >> > >>> On Fri, 02-Mar-2018 at 08:36:40 -0500, Daniel Eischen wrote: > >>>> On Fri, 2 Mar 2018, Andre Albsmeier wrote: > >>>> > >>>>> I have a MosChip 9912 card (PCIe card with 1 parallel and 2 serial > >>>>> ports) sitting here which does not get detected on 11.1. I tried > >>>>> to simply add it to the uart and ppc drivers with > >>>>> > >>>> [ ... ] > >>>> > >>>> Do you try adding similar support to puc_pci_devices[] in > >>>> sys/dev/puc/pucdata.c? > >>> > >>> Just tried that: > >>> > >>> @@ -1204,6 +1204,11 @@ > >>> PUC_PORT_1S1P, 0x10, 4, 0, > >>> }, > >>> > >>> +{ 0x9710, 0x9912, 0xa000, 0x3012, > >>> + "NetMos NM9912 Dual UART and 1284 Printer port", > >>> + DEFAULT_RCLK, > >>> + PUC_PORT_2S1P, 0x10, 4, 0, > >>> +}, > >>> { 0x9710, 0x9865, 0xa000, 0x3012, > >>> "NetMos NM9865 Dual UART and 1284 Printer port", > >>> DEFAULT_RCLK, > >>> > >>> But the results are exactly the same. It also doesn't > >>> matter if puc.ko is loaded at all. > >> > >> Are you sure your subvendor and subdevice are correct? I would > > > > No ;-). I have to use: 0x9710, 0x9912, 0xa000, 0x2000, > > > > Now I have the following behaviour: > > > > When I load puc.ko I get: > > puc0: at device 0.2 on pci9 > > > > If I load ppc.ko now, I get: > > ppc0: parallel port not found. > > > > But if I unload puc and ppc and load ppc again, I get: > > > > ppc0: port 0xd000-0xd007,0xd008-0xd00f mem 0x89200000-0x89200fff irq 20 at device 0.2 on pci9 > > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > > ppbus0: on ppc0 > > lpt0: on ppbus0 > > lpt0: Interrupt-driven port > > > > For all this I have to disable /boot/device.hints -- otherwise > > the messages "driver bug: Unable to set devclass" comes back. > > > > So I think there are two problems: > > > > First the settings of the ISA stuff in /boot/device.hints conflicted > > with the settings the driver probed. This would be easy to solve -- > > just disable them in /boot/device.hints. > > > > Second it appears that ppc only attaches if puc did some kind of > > initialisation first. But we have to detach puc so the ppc can attach. > > Strange. Did you try setting puc_load="YES" in /boot/loader.conf > and rebooting? Or are you just loading and unloading modules > for now? I am now using this diff to access the MCS9912. I am (mis)using puc to initialise whatever is needed for the printer port to work and let ppc attach to puc. As puc does not attach to single port devices, I have removed this check. uart works by simply adding the device. This is all quite ugly but it works... --- ./puc/puc.c.ORI 2018-03-06 06:21:35.939042000 +0100 +++ ./puc/puc.c 2018-03-06 06:21:10.337686000 +0100 @@ -458,8 +458,10 @@ sc->sc_cfg = cfg; /* We don't attach to single-port serial cards. */ +#if 0 if (cfg->ports == PUC_PORT_1S || cfg->ports == PUC_PORT_1P) return (EDOOFUS); +#endif error = puc_config(sc, PUC_CFG_GET_NPORTS, 0, &res); if (error) return (error); --- ./puc/pucdata.c.ORI 2016-12-27 14:33:54.000000000 +0100 +++ ./puc/pucdata.c 2018-03-06 06:19:26.764167000 +0100 @@ -1216,6 +1216,12 @@ PUC_PORT_2P, 0x10, 4, 0, }, +{ 0x9710, 0x9912, 0xa000, 0x2000, + "NetMos NM9912 Printer port", + DEFAULT_RCLK, + PUC_PORT_1P, 0x10, 4, 0, +}, + { 0xb00c, 0x021c, 0xffff, 0, "IC Book Labs Gunboat x4 Lite", DEFAULT_RCLK, --- ./uart/uart_bus_pci.c.ORI 2018-02-12 06:17:57.000000000 +0100 +++ ./uart/uart_bus_pci.c 2018-03-06 06:23:20.886245000 +0100 @@ -158,6 +158,8 @@ "MosChip MCS9904 PCIe to Peripheral Controller", 0x10 }, { 0x9710, 0x9922, 0xa000, 0x1000, "MosChip MCS9922 PCIe to Peripheral Controller", 0x10 }, +{ 0x9710, 0x9912, 0xa000, 0x1000, + "MosChip MCS9912 PCIe to Peripheral Controller", 0x10 }, { 0xdeaf, 0x9051, 0xffff, 0, "Middle Digital PC Weasel Serial Port", 0x10 }, { 0xffff, 0, 0xffff, 0, NULL, 0, 0} }; -Andre From owner-freebsd-hackers@freebsd.org Tue Mar 6 12:34:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36E18F2D1E4 for ; Tue, 6 Mar 2018 12:34:53 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [IPv6:2a01:4f8:171:f902::5]) (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 C85F574BE0 for ; Tue, 6 Mar 2018 12:34:52 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.bultmann.eu (unknown [IPv6:2a00:c380:c0d5:1:35d5:38fc:d387:8188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id 85CDE1484B for ; Tue, 6 Mar 2018 12:34:47 +0000 (UTC) Subject: Re: OpenRC 0.35 for FreeBSD To: freebsd-hackers@freebsd.org References: <20180302083756.GH34685@e.0x20.net> <35AC3784-D02B-4EB1-9F82-E522B7A7730E@FreeBSD.org> From: Jan Bramkamp Message-ID: Date: Tue, 6 Mar 2018 13:34:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <35AC3784-D02B-4EB1-9F82-E522B7A7730E@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 12:34:53 -0000 On 02.03.18 17:11, Jonathan Anderson wrote: > On 2 Mar 2018, at 12:13, Jonathan Anderson wrote: >> >> [...] there are a number of options that I've heard of vying for >> consideration: >> >>  - finit >>  - jobd (is this still a thing?) >>  - nosh >>  - OpenRC >>  - runit > > Oh, and also s6: https://skarnet.org/software/s6/why.html I've run s6 + s6-rc as init replacement for FreeBSD 11.1 on my laptop for over a year. The init_path kenv simplifies testing alternative init systems a lot. It works really well and required only minimal porting. From owner-freebsd-hackers@freebsd.org Tue Mar 6 14:16:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A292F35169 for ; Tue, 6 Mar 2018 14:16:25 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 D956078B0C for ; Tue, 6 Mar 2018 14:16:24 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qt0-x22c.google.com with SMTP id l25so24690829qtj.1 for ; Tue, 06 Mar 2018 06:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qkH3634xEBsOF69o6642VlltK0lW85CT1VcTVZ3boNc=; b=tn6UuYmMllD6iyrl2KwxFZUJEnv7yczqVEdH2vsqhBYcaaBaXf2tTKkjKLSkxxPITi 7zNHFR3i12X5VwUZEVkFiPXn8/g5hGvpTUdzxkl+obXIBxY6vzRdwd5B0MpXvGLMynJ/ W2qoQPBwiPrqMSX7nuk9OUyVWqjUXGI7LWI6Ulc9OVHZSReDqs//kmvanjcBR98Cx3uV lgT4Er/UK+Vd0chNYv4g6Ri6RXj3pV5hWTp8Sl05ND/r74GgNKb91N0g+FLpssAPxCgt NisHKmz2+xPryAnMuuzXn87V7U1IfoSPCWAzRimsSrrGTHqDb1rPb3LSBfGBEBz8da4Y 70rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qkH3634xEBsOF69o6642VlltK0lW85CT1VcTVZ3boNc=; b=K58JcHgXpBgJTkC7Ohgbk3v3eP0pe0hdi4+WF1EmcyXBK27tWSyzJ+Pbjla1O0Q89h TXtLIzVmR1CDvNzqakcjZFug7QMZ48P0jnB8bDWXm18J8lPkI8zxhAwOM4FGT8Ig/8/w NQNjcubrt/cS+sUnLLDM/FS9B5ykla1dksda+6ag/S78NEG/dqh9DbXUFl8CIRmX2l1G kNNetLAzUdBhzZqVJjg6/JdiZJJVqmYnlX3MjZUd5SScl1BUTQLbCV4iN0D8TVObgcCH GlYCZxSuOoXhFDqU8pefhLLalAhDAiq52tvoKE10vpOOzpSoiFJjpq0hRKQAZ1dKTMH3 oCBA== X-Gm-Message-State: AElRT7FP2PwX8+GfeFVAytMh6FwxaJ0OcxLYx/xigne9i+rnkF+0PQfq KKRtPRuha1kvH7+fu9SQidoe31+exSU= X-Google-Smtp-Source: AG47ELsqQmZnHxywfImOvtBjAwqxpKmTjP5q4zQL42Td/s6XQDPvZHf1mX9WyNInOThWcLhsWHBaVg== X-Received: by 10.200.35.120 with SMTP id b53mr22604192qtb.262.1520345784176; Tue, 06 Mar 2018 06:16:24 -0800 (PST) Received: from ?IPv6:2600:1017:b42f:dcb0:b57f:23b0:ed23:bf78? ([2600:1017:b42f:dcb0:b57f:23b0:ed23:bf78]) by smtp.gmail.com with ESMTPSA id t24sm3112944qtn.77.2018.03.06.06.16.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 06:16:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: S6-init was: OpenRC 0.35 for FreeBSD From: Mark Saad X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Tue, 6 Mar 2018 09:16:12 -0500 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0120B9B9-74CA-47CF-8890-574AB3DC8115@longcount.org> References: <20180302083756.GH34685@e.0x20.net> <35AC3784-D02B-4EB1-9F82-E522B7A7730E@FreeBSD.org> To: Jan Bramkamp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 14:16:25 -0000 > On Mar 6, 2018, at 7:34 AM, Jan Bramkamp wrote: >=20 >> On 02.03.18 17:11, Jonathan Anderson wrote: >>> On 2 Mar 2018, at 12:13, Jonathan Anderson wrote: >>>=20 >>> [...] there are a number of options that I've heard of vying for conside= ration: >>>=20 >>> - finit >>> - jobd (is this still a thing?) >>> - nosh >>> - OpenRC >>> - runit >> Oh, and also s6: https://skarnet.org/software/s6/why.html >=20 > I've run s6 + s6-rc as init replacement for FreeBSD 11.1 on my laptop for o= ver a year. The init_path kenv simplifies testing alternative init systems a= lot. It works really well and required only minimal porting. Jan I am interested to know more ; do you have any notes ? Also did you ever t= ry runit? Again it=E2=80=99s another similar project but if I remember it=E2= =80=99s in ports . =E2=80=94 Mark Saad | nonesuch@longcount.org > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Tue Mar 6 15:47:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66E9FF3C726 for ; Tue, 6 Mar 2018 15:47:35 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [138.201.35.217]) (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 EDBE67C4E3 for ; Tue, 6 Mar 2018 15:47:34 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from crest.bultmann.eu (unknown [IPv6:2a00:c380:c0d5:1:35d5:38fc:d387:8188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id EF58714AF1; Tue, 6 Mar 2018 15:47:26 +0000 (UTC) Subject: Re: S6-init was: OpenRC 0.35 for FreeBSD To: Mark Saad Cc: freebsd-hackers@freebsd.org References: <20180302083756.GH34685@e.0x20.net> <35AC3784-D02B-4EB1-9F82-E522B7A7730E@FreeBSD.org> <0120B9B9-74CA-47CF-8890-574AB3DC8115@longcount.org> From: Jan Bramkamp Message-ID: Date: Tue, 6 Mar 2018 16:47:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <0120B9B9-74CA-47CF-8890-574AB3DC8115@longcount.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2018 15:47:35 -0000 On 06.03.18 15:16, Mark Saad wrote: > > >> On Mar 6, 2018, at 7:34 AM, Jan Bramkamp wrote: >> >>> On 02.03.18 17:11, Jonathan Anderson wrote: >>>> On 2 Mar 2018, at 12:13, Jonathan Anderson wrote: >>>> >>>> [...] there are a number of options that I've heard of vying for consideration: >>>> >>>> - finit >>>> - jobd (is this still a thing?) >>>> - nosh >>>> - OpenRC >>>> - runit >>> Oh, and also s6: https://skarnet.org/software/s6/why.html >> >> I've run s6 + s6-rc as init replacement for FreeBSD 11.1 on my laptop for over a year. The init_path kenv simplifies testing alternative init systems a lot. It works really well and required only minimal porting. > > Jan > I am interested to know more ; do you have any notes ? Also did you ever try runit? Again it’s another similar project but if I remember it’s in ports . I used runit as init replacement on my previous laptop, but found it limitations to annoying. Runit is a pure process supervisor. The only state runit tracks are supervised processes and there are is no support for dependencies. And while it supports readiness checks those are implemented by polling every 100ms. The only way to track state with runit is to wrap it with a sleeping process. I'm still using runit on my servers. On those I have start runsv from a rc.d script. This runsv provides a default log replacing readproctile style hacks and spawns the runsvdir. The result looks like this: daemon---runsv-+-runsvdir-+-runsv-+-rspamd-1.6.6---35*[rspamd-1.6.6] | | `-svlogd | |-runsv-+-socklog | | `-svlogd | |-runsv-+-dovecot-+-anvil | | | |-auth | | | |-config | | | `-log | | `-svlogd | |-2*[runsv] | |-runsv---master-+-anvil | | |-cleanup | | |-7*[dnsblog] | | |-2*[lmtp] | | |-2*[local] | | |-pickup | | |-postscreen | | |-qmgr | | |-smtpd | | |-tlsmgr | | `-trivial-rewrite | |-runsv-+-sshd---sshd---sshd---zsh-+-cat | | | `-dtpstree | | `-svlogd | |-runsv-+-redis-server | | `-svlogd | |-runsv-+-nginx---nginx | | `-svlogd | `-runsv---spiped `-svlogd Runit is a fine process supervisor, but the development ended years ago with a "finished" product. The author decided that process supervision is enough and didn't try to write the missing service manager on top of runit. An other downside of runit compared to s6 is that it uses polling instead of proper readiness notification. If you have questions regarding s6 or s6-rc there are the #s6 (and #s6-offtopic) IRC channels on freenode and the skarware mailing lists (http://skarnet.org/lists.html#skaware). I did keep notes. I just didn't publish them because they are nothing more than an unstructured brain dump. I'm happy to answer any questions.