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 5C09C1381DF for ; Tue, 16 Feb 2016 20:00:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3535F21C00F; Tue, 16 Feb 2016 20:00:08 +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 1AB63E07FB for ; Tue, 16 Feb 2016 20:00:07 +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 E02EC340BBF for ; Tue, 16 Feb 2016 20:00:04 +0000 (UTC) Date: Tue, 16 Feb 2016 20:59:58 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Changing order of default virtual/udev provider Message-ID: <20160216205958.7c8dff26@gentoo.org> In-Reply-To: <56C374FB.1080803@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> 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: b148f35b-076b-4184-b1cc-ce7e012a9189 X-Archives-Hash: 6d72bf253b6998ee6c1c22b627e4d8c1 On Tue, 16 Feb 2016 20:14:03 +0100 Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n wrote: > Alexis Ballier schrieb: > > I also fail to see how udev using a new linux ipc would make it > > require systemd. Quoting Lennart: > > "You need the userspace code to set up the bus and its policy and > > handle activation. That's not a trivial task. For us, that's what > > sytemd does in PID 1. You'd need to come up with an alternative for > > that." > > > > 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=20 > IPC system comes next. 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. > But if upstream udev makes use of the systemd=20 > userspace interface to the kernel IPC system, then OpenRC would have > to implement the same interface in order to have working udev. 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. > Also given the close relationship between systemd and udev, there is > no guarantee that supporting other users of kdbus/bus1 will make udev=20 > automagically work. As these two are released together, there is no=20 > reason to have a stable, public API between them. Yes, which would mean systemd requires matching udev, not the other way around. I'm a bit clueless here: Do you have any pointers on the recent trends on this side ? Alexis.