Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750996AbbD3KkM (ORCPT ); Thu, 30 Apr 2015 06:40:12 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:65275 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750710AbbD3KkJ (ORCPT ); Thu, 30 Apr 2015 06:40:09 -0400 Message-ID: <55420685.8080607@nod.at> Date: Thu, 30 Apr 2015 12:40:05 +0200 From: Richard Weinberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: =?UTF-8?B?xYF1a2FzeiBTdGVsbWFjaA==?= CC: Austin S Hemmelgarn , "Theodore Ts'o" , Harald Hoyer , "linux-kernel@vger.kernel.org" Subject: Re: [GIT PULL] kdbus for 4.1-rc1 References: <21824.5086.446831.189915@quad.stoffel.home> <5540D2F9.2010704@redhat.com> <5540DEEB.2060405@redhat.com> <5540E0C7.3050106@nod.at> <5540E432.9020606@redhat.com> <5540E4D9.6000007@nod.at> <5540E684.4070606@redhat.com> <5540E821.8050204@nod.at> <5540F081.9090005@redhat.com> <20150429150341.GA12374@thunk.org> <5540F6E3.8000706@gmail.com> <871tj2ouk2.fsf%l.stelmach@samsung.com> <5541F209.8070302@nod.at> <87wq0tor57.fsf%l.stelmach@samsung.com> In-Reply-To: <87wq0tor57.fsf%l.stelmach@samsung.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pqMQEKqjgL43HnC4AvGIdcwwM5ESDFHPn" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3313 Lines: 77 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pqMQEKqjgL43HnC4AvGIdcwwM5ESDFHPn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 30.04.2015 um 12:19 schrieb =C5=81ukasz Stelmach: > It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote: >> Am 30.04.2015 um 11:05 schrieb =C5=81ukasz Stelmach: >>> Regardless, of initrd issues I feel there is a need of a local IPC >>> that is more capable than UDS. Linus Torvalds is probably right that >>> dbus-daemon is everything but effictient. I disagree, however, that >>> it can be optimised and therefore solve *all* issues kdbus is trying >>> to address. dbus-deamon, by design, can't some things. It can't >>> transmitt large payloads without copying them. It can't be made >>> race-free. >> >> This is true. >> But as long dbus-deamon is not optimized as much as possible there is >> no reason to force push kdbus. >> As soon dbus-deamon exploits all kernel interfaces as much it can and >> it still needs work (may it performance or other stuff) we can think >> of new kernel features which can help dbus-deamon. >=20 > I may not be well informed about kernel interfaces, but there are some > use cases no dbus-daemon optimisation can make work properly because of= > rece-conditons introduced by the user-space based message router. >=20 > For example, a service can't aquire credentials of a client process tha= t > actually sent a request (it can, but it can't trust them). The service > can't be protected by LSM on a bus that is driven by dbus-daemon. Yes, > dbus-daemon, can check client's and srevice's labels and enforce a > policy but it is going to be the daemon and not the LSM code in the > kernel. That's why I said we can think of new kernel features if they are needed.= But they current sink or swim approach of kdbus folks is also not the sol= ution. As I said, if dbus-daemon utilizes the kernel interface as much as possib= le we can think of new features. Thanks, //richard --pqMQEKqjgL43HnC4AvGIdcwwM5ESDFHPn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVQgaFAAoJEPmeIjfg4UaaqyEP/iQDpoIL7Onrlu4fu76lS4Eo RuJBReOCVi1ZI/5lncztaUfkte/7JlKRqqTZyhpzkfn8byBj2jso88VIllIMl1yo wiza+e2BMYJjQtwpKUI0+gJhREcXYCBCkqkNuuQoBcU/uNS10jmvvTrdOOAngmsm TJH6PMw3pmeyqzk+EaTSlYsgFPpVKyNQ6M0hOY/d2oswVWGaavAddmkkZ8AF2FkI kVr2XQG/YoA5Ka8orqTGSmewxeLU0ssJdppxL6sRqR1m1bLkZiaHvwZbP7CQEzDs PQsvvuCjlXoZP4eEC46AY8FI6BM6sUlOSVUBH7ek5Bn/Pz7bQFPtJWVwaXFgq06p kQH8hwr0wQEpOllIEkklD+zL+qbNOLjFJ3QlmpNnXL8LBafVvVgaCZ2uHquqFG1x N3h3YucS/e0w+rVd9lk+UIFedk1JiWea7PLiXaomcyx5smmoHdCFY9oE5gLmSJ3w rNVG9m9Lm97ABK92guvS87iZxBHjtExO9dTJooNmyS9yU0G/LTOFmyURyvkK3nWl la+dgfpziNBYkW4PeZjp812Xe0ivSki8Ky/kiYHG4/SNsPejvetLOHn+VDbsK828 SNJ7I7ZLdzLjoS7ruBhP1XNIiScqbXF3zOYqzqeMIrkwvNrInNii4Zv1GVJNhjzD No2dUVJt9VRwn7QIj2pq =QnOz -----END PGP SIGNATURE----- --pqMQEKqjgL43HnC4AvGIdcwwM5ESDFHPn-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/