To: Richard Weinberger <richard@nod.at>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>,
        "Theodore Ts'o" <tytso@mit.edu>, Harald Hoyer <harald@redhat.com>,
        "linux-kernel@vger.kernel.org" <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>
 <CAFLxGvzz3ac19J=dC_gWrrY=BG4h-LO+uRn2rOr1eWyVnk3vzg@mail.gmail.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>
 <55420685.8080607@nod.at>
From: =?utf-8?Q?=C5=81ukasz_Stelmach?= <l.stelmach@samsung.com>
Date: Thu, 30 Apr 2015 14:16:13 +0200
In-reply-to: <55420685.8080607@nod.at>
Message-id: <87oam5olpu.fsf%l.stelmach@samsung.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
MIME-version: 1.0
Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256;
 protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3092
Lines: 70

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
> 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 that
>> 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 solution.  As I said, if dbus-daemon utilizes the kernel
> interface as much as possible we can think of new features.

What kernel interfaces do you suggest to use to solve the issues
I=C2=A0mentioned in the second paragraph: race conditions, LSM support (for
example)?

BTW. Does anyone know how microkernel-based OSes implement sockets?
=2D-=20
=C5=81ukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVQh0NAAoJELCuHpyYpYAQmyMIAKH/nT17NtmSH4fu47uOuOZk
ByNLTp9vheRu8FeOUfhUqfcr58ovfXUEL6j2M3RUtdasbWDz3TBQmtYI8/CzOnbS
OBBzkAxy1NQoeKJZLnJW8YfS0mp3GiuVLu3c1n37Bcf3KsH4Gw/sGl5em4LbmS+5
pA5/vbvaLPbaiPcofytlZcDE1jYQI6Jevg1VRIuFLSB8lGl5ZDehRDFcMnE1Dzk0
TtS8uwYOv8oAFv8Cuw+RYe9T41Ly2bPYsKfdqjVKVQLlNfAkjZrxYfTFrWah/AqG
Xl3q4MSBHyxE18y6d3gX4azFXG0ZO/RAgr5aqJ4GVj5VJT9PXFaSI/DocNkYUU4=
=LLKT
-----END PGP SIGNATURE-----
--=-=-=--
--
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/