lkml.org 
[lkml]   [2015]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] kdbus for 4.1-rc1
    Am 29.04.2015 um 16:53 schrieb Harald Hoyer:
    > On 29.04.2015 16:18, Richard Weinberger wrote:
    >> Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
    >>>>> We don't handcraft the initramfs script for every our customers, therefore we
    >>>>> have to generically support hotplug, persistent device names, persistent
    >>>>> interface names, network connectivity in the initramfs, user input handling for
    >>>>> passwords, fonts, keyboard layouts, fips, fsck, repair tools for file systems,
    >>>>> raid assembly, LVM assembly, multipath, crypto devices, live images, iSCSI,
    >>>>> FCoE, all kinds of filesystems with their quirks, IBM z-series support, resume
    >>>>> from hibernation, […]
    >>>>
    >>>> This is correct. But which of these tools/features depend on dbus?
    >>>
    >>> I would love to add dbus support to all of them and use it, so I can connect
    >>> them all more easily. No need for them to invent their own version of IPC,
    >>> which can only be used by their own tool set.
    >>
    >> Why/how do you need to connect them?
    >> Sorry for being persistent but as I use most of these tools too (also in initramfs)
    >> I'm very curious.
    >>
    >> Many of us grumpy kernel devs simply don't know all the use case of you have to cover.
    >> So, please explain. :-)
    >>
    >
    > Well, using shell scripts I connected all of these tools in the earlier
    > versions of dracut [1]. Been there, done that.
    >
    > When using bash to wait for an interface to come up [2] or doing dhcp [3], the
    > (at least my) pain threshold is reached, and you want something more sophisticated.
    >
    > So, one starts eyeing NetworkManager or systemd-networkd. Both of them have CLI
    > tools and helpers and these tools and helpers talk to each other with (guess
    > what?) an IPC mechanism, which happens to be DBUS (because it's the IPC of
    > choice, if you don't want to reinvent the wheel).
    >
    > But let's not pinpoint that to network alone. Parsing output of tools with
    > shell scripts is horrible, slow, fragile, error prone.

    So, you want to replace bash by dbus?
    I'll stop now with arguing.
    Let's agree to disagree.

    > 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.

    This is how UNIX works. ;)

    Thanks,
    //richard


    \
     
     \ /
      Last update: 2015-04-29 17:41    [W:7.570 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site