Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Input Devices Programming XBox (Games) Linux

Linux 4.1 Bringing Many Changes, But No KDBUS 232

Posted by samzenpus from the latest-and-greatest dept.
An anonymous reader writes: The first release candidate of Linux 4.1 is now available. Linus noted, "The merge window is pretty normal in terms of what got merged too. Just eyeballing the size, it looks like this is going to fit right in — while 4.0 was a bit smaller than usual, 4.1 seems to be smack dab in the middle of the normal range for the last couple of years." There are numerous new features in Linux 4.1, like Xbox One controller force feedback support, better Wacom tablet support, Intel Atom SoC performance improvements, Radeon DisplayPort MST support, EXT4 file-system encryption, ChromeOS Lightbar support, and ACPI for 64-bit ARM, among other additions. However, KDBUS wasn't accepted for Linux 4.1.
This discussion has been archived. No new comments can be posted.

Linux 4.1 Bringing Many Changes, But No KDBUS More

Linux 4.1 Bringing Many Changes, But No KDBUS

Comments Filter:

  • KDBus - another systemd brick on the wall (Score:3, Insightful)

    by Anonymous Coward on Monday April 27, 2015 @04:06AM (#49558549)

    Say what you want, systemd already whack too much havoc for Linux and I do not wish to see yet another systemd brick inside the Linux Kernel

    ... KDBUS is aimed to be a new kernel IPC mechanism inspired by D-Bus. KDBUS is being sought after by systemd ...

    • Re:KDBus - another systemd brick on the wall (Score:5, Insightful)

      by geekmux ( 1040042 ) on Monday April 27, 2015 @04:15AM (#49558571)

      Say what you want, systemd already whack too much havoc for Linux and I do not wish to see yet another systemd brick inside the Linux Kernel

      ... KDBUS is aimed to be a new kernel IPC mechanism inspired by D-Bus. KDBUS is being sought after by systemd ...

      Well, don't forget while we're waiting, really important shit got added to the kernel.

      After all, what good is a Linux distro without XBox One controller force feedback support.

      • Re: (Score:3, Insightful)

        by Chris Katko ( 2923353 )
        >XBox One controller force feedback support.

        You mean the de facto standard [steampowered.com] controller for PC gaming these days?

        1) People complain about poor driver support in Linux every year. It's been getting better. This is an example.

        2) Adding feedback to Xbox controllers is a minor change compared to adding an entire, new IPC interface for systemd.

        3) Kernel changes are not a zero-sum game. Just because some kid in college wants his controller to work and submits a patch, doesn't mean Linus cries himself to

    • Re:KDBus - another systemd brick on the wall (Score:5, Interesting)

      by Anonymous Coward on Monday April 27, 2015 @04:16AM (#49558575)

      Which is good. Systemd has already stated they will hard depend on it and equally a systemd bump will require a bump of the kernel.
      For those that are on systemd then finding themselves in a situation where an upgrade/downgrade of either the kernel or systemd (oh I don't know... due to a issue) renders the system unbootable is worrying...

      How much longer can non-systemd hold out (with gnome/kde swallowing it ...)? how long until it is wrapped in that behemoth that is PID1.
      It isn't the UNIX way... its the windows way with svchost.exe & binary logs... and we all know how well that works.
      Not only that but Systemd has shown to be hostile to that which it has assimilated...

      https://lkml.org/lkml/2015/4/15/104

      > To make this clear, we expect that systemd and kernels are updated in
      > lockstep. We explicitly do not support really old kernels with really
      > (which means 3.4 right now), but even that should be taken with a grain
      > of salt, as we already made clear that soon after kdbus is merged into
      > the kernel we'll probably make a hard requirement on it from the systemd
      > side.

      Thats plenty clear, isnt it? As soond as kdbus is merged into kernel,
      systemd will depend on it, and then if I need to go back to older kernel,
      I have to downgrade systemd as well?

      http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdAndSyslog
      Anyone who works with systemd soon comes to realize that systemd just doesn't like syslog very much. In fact systemd is so unhappy with syslog that it invented its own logging mechanism (in the form of journald). This is not news. What people who don't have to look deeply into the situation often don't realize is that systemd's dislike is sufficiently deep that systemd just doesn't interact very well with syslog.

      I won't say that bugs and glitches 'abound', because I've only run into two issues so far (although both issues are relatively severe). One was that systemd mis-filed kernel messages under the syslog 'user' facility instead of the 'kernel' one; this bug made it past testing and into RHEL 7 / CentOS 7. The other is that sometimes on boot, randomly, systemd will barf up a significant chunk of old journal messages (sometimes very old) and re-send them to syslog. If you don't scroll back far enough while watching syslog logs, this can lead you to believe that something really bad and weird has happened.

      • Re:KDBus - another systemd brick on the wall (Score:4, Interesting)

        by ledow ( 319597 ) on Monday April 27, 2015 @05:09AM (#49558671) Homepage

        Systemd is one of those thing that people know will end in disaster. Sure, it works at the moment. But a personality will jump into it, or a bug will catch up with their design, or something else. And it will all come crashing down.

        What bugs me about systemd is not the idea behind systemd. It's the implementation. Using cgroups and other kernel-provided features, it's able to provide functionality that we don't have elsewhere. But rather than break-down that functionality and make each part replaceable, and use "old" methods to do some things while they are replaced with "new" methods.

        It's the all-or-nothing nature of systemd that I hate. There's no reason it can't be done in some other way. There's no reason that, even at a base level, you can't write scripts that do the same as it does - for all functions, but also for parts of the functions. As such, it's not modular, not changeable, it's just a lump of code that you accept having complete control of your machine or not. And I don't.

        Honestly, I'm waiting for the crash-and-burn moment at which someone steps up, gives us the same features, using predictable, modular code or even scripts, and we can put in the bits we like and leave out the bits we don't like and replace any bit and NOBODY will know or care that we've done that.

        • Re: (Score:2, Interesting)

          by Peter H.S. ( 38077 )

          Systemd is one of those thing that people know will end in disaster. Sure, it works at the moment. But a personality will jump into it, or a bug will catch up with their design, or something else. And it will all come crashing down.

          Sure, many systemd-opponents harbour fantasies like that. Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design, that the systemd design is bad and that the code is bad, it puzzles them that despite all this, systemd have worked beautifully for so many years.

          But the brutal and inescapable fact is that systemd is coded and designed by top notch, seasoned Linux programmers that really knows their stuff well, and that systemd also work really well and so

          • Re: (Score:3, Informative)

            by segedunum ( 883035 )

            Sure, many systemd-opponents harbour fantasies like that.

            Many systemd proponents harbour fantasies of it being the one true way of doing......anything and want to wave away the problems.

            This, by the way, is Linus's take on kdbus and why it won't be seen in the kernel for some time to come, if ever:

            http://lkml.iu.edu//hypermail/... [iu.edu]

            Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed.

            This has been going on for *years*, and doesn't seem to be getting any better. This is relevant to you because I have seen you talk about the kdbus patches, and this is a heads-up that you need to keep them separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers.

            Regardless of any other bullshit and hearsay, that is the policy of the kernel. When he says 'Kay', read any systemd developer. Oh, and no, it's not a joke and no he doesn't write the e-mails on the kernel mailing list for the goo

          • Re: (Score:3, Insightful)

            by ledow ( 319597 )

            Seasoned programmers that "know their stuff" that have been told to keep their un-maintained junk out of the kernel before now? And in no polite terms?

            "Worked beautifully" resulting in many unbootable (or, worse, variably bootable) systems over the years. It's far from perfect (I'm not expecting perfect, but it's far from it).

            Though I don't doubt that there are entire swathes of people happy with it, that there is so much opposition is not only indicative that it's far-from-perfect, but that many people m

          • Re: (Score:2)

            by jbolden ( 176878 )

            Wow wish I could mod you up. Your last paragraph is spot on.

          • Sure, many systemd-opponents harbour fantasies like that. Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design, that the systemd design is bad and that the code is bad, it puzzles them that despite all this, systemd have worked beautifully for so many years.

            You missed one. "Anyone who stands up for systemd doesn't know anything bout Linux. Because if they knew anything about Linux, they would hate systemd." Its a rinse and repeat situation.

            But as you've noted, many have graduated to the systemdpocalypse mode, of saying "Just you wait! You'll see! You'll see!" mode.

          • Since they claimed that the systemd developers are bad and inexperienced programmers that can't code or design,

            We have seen this proven true with pulseaudio.

            that the systemd design is bad and that the code is bad,

            Which should surprise nobody

            it puzzles them that despite all this, systemd have worked beautifully for so many years.

            Which it hasn't, and many slashdotters have given examples in this and other systemd-related threads, which you have willfully ignored because they don't fit the narrative you swallowed.

          • Re:KDBus - another systemd brick on the wall (Score:4, Informative)

            by Anonymous Coward on Monday April 27, 2015 @09:57AM (#49560371)

            "Working" is not a very high bar to meet when you're talking about something as simple as an init system. init systems are not at all hard to write. They start programs according to rules and restart them if they quit or crash. Read a config file, fork() off your children, then use waitpid()/waitid() with W_NOHANG in a loop to handle terminations. The sysvinit code used by all Linux distros until SystemD reared its ugly head had been floating around has been effectively without a maintainer for probably decades. And that was fine because the code was so damn simple any competent coder could clone it in his sleep if necessary.

            So SystemD's cloning sysvinit is not particularly impressive. Dumping everything and the kitchen sink into the same source tree is also not particularly impressive. Not supporting any OSes other than Linux because it would cramp their brogrammer style is another thing that makes them look bad.

            I don't know if SystemD will ultimately crash and burn. I can't predict the future. But, if these clowns keep going as they are, good chance.

          • Re:KDBus - another systemd brick on the wall (Score:5, Interesting)

            by Anonymous Coward on Monday April 27, 2015 @10:33AM (#49560705)

            But the brutal and inescapable fact is that systemd is coded and designed by top notch, seasoned Linux programmers that really knows their stuff well, and that systemd also work really well and solves so many old problems.

            Since you resorted to an ad hominem argument, I'll follow this up. The initiator of systemd is Lennart Poettering, who was also responsible for the pulseaudio and avahi projects. I discovered pulseaudio when Ubuntu implemented it ~7 years ago, and my audio randomly started breaking. A release or two later (6+ months) it was fixed, and audio worked the same as it had before, except that I've noticed pulseaudio occasionally using a few percent of my CPU. Avahi is apparently a service that allows me to make printers connected to my computer available to other computers on the network, which I've never used - but I've still noticed it occasionally at the top of "top" in CPU usage. I'm using a laptop: when a process advertising non-existent printers is sometimes the number one drain on my battery, that's a problem.

            So the head programmer of systemd has previously been responsible for projects that did nothing of any benefit to me, caused occasional instability and breakage, and consumed resources unnecessarily. That doesn't tell me that he's a "top notch, seasoned Linux programmer". It tells me that he's a poor architect, probably an indifferent programmer - but very, very good at politicking to get projects incorporated into distros when they shouldn't be. Why should I think that systemd is any different?

            • "caused occasional instability and breakage, and consumed resources unnecessarily", Virtually every program written has done that due to some bug or other so that comment of yours makes the rest of your post baseless and not worth replying to.

              • Re: (Score:3)

                by pem ( 1013437 )

                Virtually every program written has ["caused occasional instability and breakage, and consumed resources unnecessarily"]

                Yes and "virtually every program" is something that the user voluntarily and directly starts. Avahi, pulseaudio, and systemd... aren't. Which makes it exceptionally frustrating for both users and developers when there is a problem, both from a standpoint of not knowing where the problem came from, and from the standpoint of finding an alternate program to use instead.

                Which is why sy

        • Re: (Score:2)

          by jbolden ( 176878 )

          There's no reason that, even at a base level, you can't write scripts that do the same as it does - for all functions, but also for parts of the functions

          Actually there is. Systemd does lots of things that run at very low levels and thus performance matters. Processes that run multiple times per second aren't scripted in Unix. Unix has always accepted that you use a high level scripting language to tie together low level binary function, not that you script the whole system. What you are asking for i

      • Poettering thinks he's the next Linus (Score:4, Insightful)

        by Viol8 ( 599362 ) on Monday April 27, 2015 @06:02AM (#49558779) Homepage

        Saidly too many people are believing this delusion. I can't help thinking thats one reason why systemd is taking over - its not that its any good , its who wrote it. Which is mystifying given what a POS PulseAudio was/is.

        • 1. PulseAudio was good. The initial packaging in some distributions were however questionable.
          2. Systemd is good, and the quality of it has nothing to do with PulseAudio.

      • Re:KDBus - another systemd brick on the wall (Score:4, Informative)

        by Peter H.S. ( 38077 ) on Monday April 27, 2015 @06:13AM (#49558817) Homepage

        Which is good. Systemd has already stated they will hard depend on it and equally a systemd bump will require a bump of the kernel.
        For those that are on systemd then finding themselves in a situation where an upgrade/downgrade of either the kernel or systemd (oh I don't know... due to a issue) renders the system unbootable is worrying...

        A typical misunderstanding by people quoting a systemd-devel mail out of context. They don't intent to keep the kernel and systemd in lock step for every release. They haven't done before so why should they do it in the future. What they do want to do is require kdbus kernels in the future, and that will bumb the minimum kernel version from 3.8 (or whatever) to 4.2 (or whatever).

        At the time when such an edition hits stable distros, there will be no problems with downgrading to a previous kdbus enabled kernel.

        Also remember that systemd follows the same pattern as the kernel development with bleeding edge releases and long term stable releases. Nobody is forcing anybody to use the newest systemd available, use a long term stable version (208, 215 etc) if you please.

      • Comment removed based on user account deletion

        • SystemD doesn't in any way resemble the "Windows way", stop being ridiculous.

          Yes, it absolutely does. It ties functionality together in a way which is designed to be difficult to tease apart specifically because of NIH.

  • Please stop the Phoronix shouting! (Score:3, Insightful)

    by Anonymous Coward on Monday April 27, 2015 @04:34AM (#49558603)

    The original announcement from Linus says: No earth-shattering new features come to mind. Yet Phoronix and now also Slashdot are shouting: "numerous features!", and then listing a few things which will not matter for most users. Can we please not follow this Phoronix shouting mentality and stay a bit more realistic and neutral?

    • Re:Please stop the Phoronix shouting! (Score:5, Funny)

      by discord5 ( 798235 ) on Monday April 27, 2015 @06:18AM (#49558835)

      Yet Phoronix and now also Slashdot are shouting: "numerous features!

      Just wait until they benchmark that xbox controller force feedback. They'll have useful graphs such as "Bootup time with and without xbox controller (lower is better)", "Strenght of feedback on odd and even numbered seconds (higher is better)", and the ever so important "Adbucks generated by pointless benchmarks on an xbox conroller (higher is better)".

      Hell, I can't wait to see the graphs on that last one.

    • Re: (Score:3)

      by jandrese ( 485 )
      EXT4 encryption seems like a pretty good bullet point, especially with the TrueCrypt situation. I hope it's not fatally flawed in some way. Caveat: I have not looked at it yet.

  • AGP not working with SMP (Score:4, Informative)

    by jones_supa ( 887896 ) on Monday April 27, 2015 @05:26AM (#49558701)
    I hear [reddit.com] that due to some KMS changes, AGP on SMP is currently broken.

  • Oh grow up (Score:5, Insightful)

    by Anonymous Coward on Monday April 27, 2015 @06:18AM (#49558837)

    KDBUS is just another IPC mechanism, and while it might need a little more work before going mainline, its not some evil systemd plot to take over the world. I think its time some of you put down the tin foil hat, take a deep breath, calm down and look at it as the IPC interface that it is.

    DBUS is used by lots of none systemd projects as a user space IPC currently, moving it to the kernel will help with performance, and potentially security. If some of you stopping look at every thing systemd tinted glasses you might start reacting like rational adults.

    The issue of systemd and the kernal needed to be down/up-graded in lock step will probably turn into an none issue on the server side. That kernel/systemd version will not just be introduced as an update to RHEL etc, it will be held back for a major version change. So any hardware regression issues will only hit when doing an OS re-install which is always a risk, the kernel/systemd lock step will make no difference here.

    • If some of you stopping look at every thing systemd tinted glasses you might start reacting like rational adults.

      Funny you should say that, AC. I'll wait (not holding my breath though) for the rational, adult answer of G H-K to this message and a timeline for addressing the issues it raised:

      http://lkml.iu.edu/hypermail/l... [iu.edu]

      To quote the last part:

      Not that this complaint is not in any sense new you have been ignoring people who try to bring up meaningful issues for a long time. The fact that when people bring up uncomfortable points about the kdbus code they get routingely blown off certainly contributes to the lack of meaningful review as it is not rewarding to work with someone who does not listen to criticism. At this point the strongest possible language and the strongest possible push back are being used because everything else is routinely swept under the rug.

      So, feel free to engage in that rational discussion anytime now.

    • KDBUS is just another IPC mechanism, and while it might need a little more work before going mainline, its not some evil systemd plot to take over the world. I think its time some of you put down the tin foil hat, take a deep breath, calm down and look at it as the IPC interface that it is.

      Well, Kdbus is more than just simple IPC, it is also provide a control framework with policies etc. just like dbus does.

      What the tin-foil brigade don't understand, that any non-dbus compatible IPC will be a major problem for all non-systemd distros and BSD variants, since it per default will be Linux only, and in reality a systemd-only affair, since only systemd distros will have the developer manpower to implement and support the necessary userspace libraries.

      With Kdbus, userland can just continue to use l

      • Re: (Score:2)

        by Dog-Cow ( 21281 )

        Read the entire LKML thread. You are wrong, but I don't feel like regurgitating several dozen emails in a slashdot post to illustrate why. The link is in the Phoronix article.

    • Re: (Score:3)

      by DarkOx ( 621550 )

      moving it to the kernel will help with performance, and potentially security.

      Performance likely, because data can actually be shoveled between processes with probably greater concurrency than with a third user land context in the mix.

      Security I don't see how, moving it in the kernel is an improvement. You add all the risks associated with being able to step all over systemically important data structures to a "process" that by definition has to communicate with a largish number of less trusted processes. If you limit who/what is allowed to talk to dbus with a firewall like soluti

      • Security I don't see how, moving it in the kernel is an improvement. You add all the risks associated with being able to step all over systemically important data structures to a "process" that by definition has to communicate with a largish number of less trusted processes. If you limit who/what is allowed to talk to dbus with a firewall like solution you make dbus less useful as an IPC channel.

        Kdbus will really will provide several layers of extra security since LSM's like SELinux can hook into the system from the kernel and not in the much less secure userspace. You also gain kernel guarantee for the message marshalling.

        The performance considerations might be a justification but I have never really seen DBUS as a high performance IPC channel anyway.

        That is exactly because dbus is extremely slow when it comes to data transport.

        Maybe I am just badly misinformed on its planned usecases. I thought it was for deriving simple short messages like "A new input device is a available" not shoveling megabytes of data between processes. We have fifo pipes and UNIX sockets for that, and if latency is an issue there is always shared memory.

        The point is that many developers, especially embedded and IVI (and DE's like Gnome and KDE) are interested in using the same framework for both control and data. Having side channels to dbus in order

        • Re: (Score:2)

          by DarkOx ( 621550 )

          Thanks for the link very interesting, and helpful. I am not sure I fully buy the security argument, mainly because most of the time I don't see the LSMs themselves adding much value; but the points about DOS resistance and keeping the work load in the senders own timeslice being generally desirable makes sense.

    • As a programmer, KDBUS (or any proper IPC system for Linux) sounds really useful.

      Here is a write-up on DBUS vs KDBUS [lwn.net] for those who are interested.

      To sum up: D-Bus is great for sending control messages ("change volume") but not for lots of data (audio streams), it's not available at boot-time (a serious problem if you need to talk to it!), and it's got security flaws. KDBUS is the incremental solution to these problems. A kernel space message sending system that all programs can use at boot to talk to ea

  • STOP LINKING TO PHORONIX (Score:3)

    by Theovon ( 109752 ) on Monday April 27, 2015 @07:43AM (#49559157)

    It's possible that Michael Larabel didn't get his facts wrong this time, but he has a history of (a) sloppy reporting and (b) completely ignoring requests for making corrections. Considering the number of times his mistake was pointed out in this one case (https://twitter.com/phoronix/status/575005596501590016, http://www.phoronix.com/forums/showthread.php?115543-An-LGPL-Licensed-Larrabee-Inspired-GPGPU-Processor/page2), I think he does it on purpose just to fuck with people.

    • history of (a) sloppy reporting and (b) completely ignoring requests for making corrections.

      So 100% Slashdot-compatible? ;)

  • For all the noise about systemd, we are totally ignoring the fact that it's the Linux kernel that is the most egregious violation of UNIX modular philosophy. ChromeOS Lightbar has no place in main kernel distribution. System should at least provide enough of a stable binary interface for users to get a binary from outside developer and use it for a couple years. It's not crazy for a non-critical driver like this run in userspace, where a crash is less likely to bring down the whole system.

    Anyone interested

Slashdot Top Deals

Ummm, well, OK. The network's the network, the computer's the computer. Sorry for the confusion. -- Sun Microsystems

Close