From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 145681388BF for ; Wed, 17 Feb 2016 13:03:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B6CA721C00F; Wed, 17 Feb 2016 13:03:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 94EB7E0869 for ; Wed, 17 Feb 2016 13:03:36 +0000 (UTC) Received: from localhost (dra13-4-78-234-166-189.fbx.proxad.net [78.234.166.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id E3E14340B66 for ; Wed, 17 Feb 2016 13:03:34 +0000 (UTC) Date: Wed, 17 Feb 2016 14:03:27 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider Message-ID: <20160217140327.6833458e@gentoo.org> In-Reply-To: <20160217135851.68b7c554.mgorny@gentoo.org> References: <20160214114131.62b2deb8.dolsen@gentoo.org> <20160214202326.GE7732@vapier.lan> <20160214203454.GF7732@vapier.lan> <56C0E7E8.9090901@gentoo.org> <20160214205038.GI7732@vapier.lan> <56c12b45.aa22b60a.9e156.4fd5@mx.google.com> <20160215102900.1693a1de@gentoo.org> <20160216174541.GA1450@whubbs1.gaikai.biz> <20160216191240.5359430f@gentoo.org> <56C36BAC.3080602@gentoo.org> <20160216200516.6318fd16@gentoo.org> <56C374FB.1080803@gentoo.org> <20160216205958.7c8dff26@gentoo.org> <56C3A59D.7070409@gentoo.org> <20160217134334.090671cc.mgorny@gentoo.org> <72D09430-E727-4E2C-9A89-04CAF7D3A405@gentoo.org> <20160217135851.68b7c554.mgorny@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c1c84082-e9a9-48fc-9068-04175a94191a X-Archives-Hash: e7a6b061b3f196e7c3c70e0159e7037b On Wed, 17 Feb 2016 13:58:51 +0100 Micha=C5=82 G=C3=B3rny wrote: > On Wed, 17 Feb 2016 07:53:22 -0500 > Richard Yao wrote: >=20 > > > On Feb 17, 2016, at 7:43 AM, Micha=C5=82 G=C3=B3rny > > > wrote: > > >=20 > > > On Tue, 16 Feb 2016 23:41:33 +0100 > > > Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n wrote: > > > =20 > > >> Alexis Ballier schrieb: =20 > > >>>>> If it's just that, it's not limited to udev, but anything > > >>>>> using kdbus/bus1, and would mean openrc/${favorite init > > >>>>> system} will have to do the same thing anyway. But again, > > >>>>> almost 2 years is extremely old considering all the flux that > > >>>>> has been around kbus. =20 > > >>>>=20 > > >>>> OpenRC itself can for now just ignore kdbus, bus1, or whatever > > >>>> kernel IPC system comes next. =20 > > >>>=20 > > >>> Well, as Lennart wrote it, kbus would have needed some > > >>> initialisation. Just like we have a dbus init script, openrc > > >>> would have a kdbus one.=20 > > >>>> But if upstream udev makes use of the systemd > > >>>> userspace interface to the kernel IPC system, then OpenRC > > >>>> would have to implement the same interface in order to have > > >>>> working udev. =20 > > >>>=20 > > >>> As I understand it, a kernel IPC doesn't need systemd to work. > > >>> udev might use wrappers from libsystemd, or libbus1, just like > > >>> we have programs using libv4l or libbluetooth currently. =20 > > >>=20 > > >> In a follow-up, upstream wrote about how you should only run > > >> udev together with systemd, and if you don't want to do that > > >> (spelling as in original): > > >>=20 > > >> "we will not support the udev-on-netlink case anymore. I see > > >> three options: a) fork things, b) live with systemd, c) if hate > > >> systemd that much, but love udev so much, then implement an > > >> alternative userspace for kdbus to do > > >> initialiuzation/policy/activation." > > >> https://lists.freedesktop.org/archives/systemd-devel/2014-May/019664= .html > > >>=20 > > >> So it seems a bit more than only initialization is needed. =20 > > >=20 > > > You're missing the third option which is a sane option, and jump > > > straight to pitchforks. > > >=20 > > > As I see it, *if* this becomes a necessity, we're quite like are > > > going to provide KDBUS parts of systemd the way we provide udev > > > parts right now. After all, libsystemd-bus will be useful to more > > > applications. > > >=20 > > > Of course, someone may want to fork that into libebus just for > > > the sake of renaming. > > >=20 > > > And after all, as it has already been noted, there are people > > > interested in maintaining non-systemd userspace for KDBUS. Which > > > is kinda the obvious choice, unlike forking something. =20 > >=20 > > kdbus is dead. It is fatally flawed and Greg is no longer trying to > > get it merged as he is not updating his branch for newer kernel > > versions. If I recall correctly, kdbus was also removed from Fedora > > and has no distribution backing it anymore. =20 >=20 > Then... why are we even discussing this? >=20 because s/kdbus/bus1/