[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <871tj2ouk2.fsf%l.stelmach@samsung.com>
Date: Thu, 30 Apr 2015 11:05:17 +0200
From: Łukasz Stelmach <l.stelmach@...sung.com>
To: Austin S Hemmelgarn <ahferroin7@...il.com>
Cc: Theodore Ts'o <tytso@....edu>, Harald Hoyer <harald@...hat.com>,
Richard Weinberger <richard@....at>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
It was <2015-04-29 śro 17:21>, when Austin S Hemmelgarn wrote:
> On 2015-04-29 11:03, Theodore Ts'o wrote:
>> On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote:
>>> Sure, I can write one binary to rule them all, pull out all the code from all
>>> tools I need, but for me an IPC mechanism sounds a lot better. And it should be
>>> _one_ common IPC mechanism and not a plethora of them. It should feel like an
>>> operating system and not like a bunch of thrown together software, which is
>>> glued together with some magic shell scripts.
>>
>> And so requiring wireshark (and X?) in initramfs to debug problems
>> once dbus is introduced is better?
>>
>> I would think shell scripts are *easier* to debug when things go
>> wrong,
[...]
> I keep hearing from people that shell scripting is hard, it really
> isn't compared to a number of other scripting languages, you just need
> to actually learn to do it right (which is getting more and more
> difficult these days cause fewer and fewer CS schools are teaching
> Unix).
My 2/100 of a currency of your choice.
As much as I like(ed) shell scripts as a boot up tool and disliked
obscure boot-up procedures of some operating system, I can't help but
notice that GNU/Linux distributions have become very
sophisticated/complcated (cross out if not applicable). Personally
I feel that this degree of coplexity can't be supported by shell scripts
piping data around. It does not scale. I am not 100% sure a new IPC is
the answer, simply because I do not have experience to be so. It
definitely can be and the problem, as I see it, is real.
(The alternative answer is PowerShells capability to pipe objects. I
don't like it and I thik it's not a full answer.)
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.
Kind regards,
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
Download attachment "signature.asc" of type "application/pgp-signature" (473 bytes)
Powered by blists - more mailing lists