View previous topic :: View next topic |
Author |
Message |
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Wed Dec 09, 2015 5:01 pm Post subject: Kdbus is dead, long live bus1 |
|
|
https://github.com/bus1 _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6100 Location: Dallas area
|
|
Back to top |
|
|
gwr Apprentice
Joined: 19 Nov 2014 Posts: 194
|
Posted: Thu Dec 10, 2015 5:39 pm Post subject: |
|
|
So it's a complete re-write. Years of man effort go into kdbus and it's just tossed? Wow. |
|
Back to top |
|
|
miket Guru
Joined: 28 Apr 2007 Posts: 488 Location: Gainesville, FL, USA
|
Posted: Thu Dec 10, 2015 10:36 pm Post subject: |
|
|
From the Phoronix article: Quote: | but systemd developer David Herrmann and Kay Sievers seem to be the lead (and only) developers working on it | You mean Sievers the Incorrigible? That guy whose code is embargoed from being merged into the kernel?
Oh, they're putting their best talent on it, aren't they? |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6100 Location: Dallas area
|
Posted: Thu Dec 10, 2015 10:54 pm Post subject: |
|
|
miket wrote: | From the Phoronix article: Quote: | but systemd developer David Herrmann and Kay Sievers seem to be the lead (and only) developers working on it | You mean Sievers the Incorrigible? That guy whose code is embargoed from being merged into the kernel?
Oh, they're putting their best talent on it, aren't they? |
*snicker* _________________ PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
ppurka Advocate
Joined: 26 Dec 2004 Posts: 3256
|
Posted: Fri Dec 11, 2015 12:03 am Post subject: |
|
|
This time it's out of tree: "Bus1 Out-of-Tree Kernel Module". I suspect, with libbus1, they might propose to replace dbus. Let's see how this saga turns out. _________________ emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/ |
|
Back to top |
|
|
john.newman Tux's lil' helper
Joined: 17 Oct 2009 Posts: 85
|
Posted: Fri Dec 11, 2015 3:51 am Post subject: |
|
|
Wow. As the page turns. These guys have me on a popcorn only diet, I don't think I can keep up much longer.
I am so glad we have gentoo which is free / highly optional of these antics. It's like watching your neighbors fight all the time from a safe comfortable distance. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sat Mar 26, 2016 12:09 pm Post subject: |
|
|
http://www.bus1.org/ _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sat Mar 26, 2016 2:23 pm Post subject: |
|
|
Are those guys refugees from Redmond or what? Maybe they are going to rename their distro "Redmond Hat". |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3509
|
Posted: Sat Mar 26, 2016 3:21 pm Post subject: |
|
|
Naib wrote: | http://www.bus1.org/ |
Waitaminnit!
Looking at those pages, this is an init system, not just a dbus replacement. This is bundling kdbus and systemd together under a new name.
I suspect that SOMEBODY has realized that some poor design decisions were made in systemd, and can't bear the thought of admitting it. I've not looked long enough to compare bus1 to systemd to know what has changed. It's too close to lunch time, I don't think looking now would be a good idea. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Mar 26, 2016 4:34 pm Post subject: |
|
|
edit: the technical part has been discussed to death, already.
depontius wrote: | This is bundling kdbus and systemd together under a new name. |
That is an awful idea; systemdbust is already a tangle-fest of unrelated projects.
Quote: | I suspect that SOMEBODY has realized that some poor design decisions were made in systemd, and can't bear the thought of admitting it. |
Well, I'm sure that's true, but I don't think it's worth everyone waiting 10-20 years til they end up where openrc was 5 years ago.
I think it's more likely they're trying to enforce the dbust lock-in: next phase would be another "gentle Putsch" to make it so the "big" DEs (like GNOME and KDE) require it, and thus "leverage" the dbust lock-in to a systemdbust lock-in.
Truth is, if you were going to do "kdbust" as a userland library, you'd use TIPC and not do anything other than provide the mechanisms.
Then you'd leave it up to consumers to do whatever they wanted. (the privileged end would enforce a protocol.)
Unless ofc you have an ulterior reason to shove everything in one "modular blob", and make the transport so much less useful.
Last edited by steveL on Mon Mar 28, 2016 12:53 pm; edited 1 time in total |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sat Mar 26, 2016 6:43 pm Post subject: |
|
|
Sounds like it's called bus1 because they want the Linux desktop ecosystem to have a Bus Factor of 1. |
|
Back to top |
|
|
khayyam Watchman
Joined: 07 Jun 2012 Posts: 6227 Location: Room 101
|
Posted: Sat Mar 26, 2016 7:24 pm Post subject: |
|
|
Ant P. wrote: | Sounds like it's called bus1 because they want the Linux desktop ecosystem to have a Bus Factor of 1. |
Ant ... or a Max Factor of long-lasting kissable lips ... zo zexy ;)
best ... khay |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sat Mar 26, 2016 7:37 pm Post subject: |
|
|
depontius wrote: | Naib wrote: | http://www.bus1.org/ |
Waitaminnit!
Looking at those pages, this is an init system, not just a dbus replacement. This is bundling kdbus and systemd together under a new name.
I suspect that SOMEBODY has realized that some poor design decisions were made in systemd, and can't bear the thought of admitting it. I've not looked long enough to compare bus1 to systemd to know what has changed. It's too close to lunch time, I don't think looking now would be a good idea. | that's what is really confusing me...
http://www.bus1.org/org.bus1.init.html
Quote: | org.bus1.init — Init Process
Description
org.bus1.init is executed by org.bus1.rdinit(1) and runs as PID1. It is responisble for starting the org.bus1.activator(1) and org.bus1.administrator(1) services.
See Also
org.bus1.activator(1), org.bus1.rdinit(1), org.bus1.bootstrap(1), Git repository |
http://www.bus1.org/org.bus1.rdinit.html
Quote: | org.bus1.rdinit — Initramfs Init Process
Description
org.bus1.rdinit is part of the initramfs image. It is executed as /init by the kernel and runs as PID 1. |
So the kernel is now meant to call bus1 that calls systemd? _________________
Quote: | Removed by Chiitoo |
Last edited by Naib on Mon Mar 28, 2016 11:35 am; edited 2 times in total |
|
Back to top |
|
|
bstaletic Apprentice
Joined: 05 Apr 2014 Posts: 253
|
Posted: Sat Mar 26, 2016 9:48 pm Post subject: |
|
|
Please correct me when I make a mistake... Kdbus was supposed to be a kernel module and if failed. Bus1 was started, supposedly from scratch, as a "sane" alternative. Bus1 integrates init system (my assuption: systemd-init). If bus1 were supposed to replace kdbus it would have had to have a kernel module. Linus, being a person I think he is, won't allow a code base the size of ~30% of the rest of the kernel (last time I checked) inside. Even if Linus doesn't say "no", there were other kernel developers around him poiniting out security issues of kdbus that are still there.
This also seems to me like the attempt of ending dbus in favour of bus1. I won't say anything about the org.ugly.naming.convention, except that it can easily break zsh's completion.
EDIT:
Umm... org.bus1.devices?? Is that the long awaited sd-devices? Seems like it. Oh, I also fount the kernel modules ont their home page. Does anyone else think of the only purposely non posix compliant OS while reading about this? |
|
Back to top |
|
|
digi_owl n00b
Joined: 04 Oct 2015 Posts: 9
|
Posted: Sun Mar 27, 2016 12:52 pm Post subject: |
|
|
One of the incentives for kdbus was that car companies had begun adopting Linux for their in-car computing needs, replacing QNX.
Thing is that QNX had a in-kernel RPC bus that behaved somewhat like dbus. So said companies adopted dbus as a replacement. But with dbus sitting in user space, it didn't have the same performance characteristics as what is was replacing. And so the companies started pushing for a in-kernel version of dbus.
What i am speculating is that bus1 is aimed at being a complete solution. A minimal init and device manager, and a in-kernel RPC to tie it all together.
That said, the in-kernel RPC stuff of bus1 seems to be protocol agnostic. Thus it would not surprise me if we see the kernel stuff being used without the init stuff (if possible) to speed up dbus. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sun Mar 27, 2016 1:19 pm Post subject: |
|
|
you can't compare QNX and Linux. One is an RTOS, one is a mult-functional OS.
the ICE is not the only part of a car and the backbone of car's is usually CAN, a fantastic protocol _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
bstaletic Apprentice
Joined: 05 Apr 2014 Posts: 253
|
Posted: Sun Mar 27, 2016 2:29 pm Post subject: |
|
|
Naib wrote: | CAN, a fantastic protocol |
I don't know much about RTOS and I have no idea what ICE is, but I've done research about CAN just enough so I can implement it in my current project (I'm only talking about source code here) and fantastic seems quite apropriate. |
|
Back to top |
|
|
bstaletic Apprentice
Joined: 05 Apr 2014 Posts: 253
|
Posted: Sun Mar 27, 2016 2:35 pm Post subject: |
|
|
digi_owl wrote: | One of the incentives for kdbus was that car companies had begun adopting Linux for their in-car computing needs, replacing QNX.
Thing is that QNX had a in-kernel RPC bus that behaved somewhat like dbus. So said companies adopted dbus as a replacement. But with dbus sitting in user space, it didn't have the same performance characteristics as what is was replacing. And so the companies started pushing for a in-kernel version of dbus.
What i am speculating is that bus1 is aimed at being a complete solution. A minimal init and device manager, and a in-kernel RPC to tie it all together.
That said, the in-kernel RPC stuff of bus1 seems to be protocol agnostic. Thus it would not surprise me if we see the kernel stuff being used without the init stuff (if possible) to speed up dbus. |
The first line doesn't make much sense to me because of what Naib wrote. And as far as I know with RTOS there's no userspace, one is supposed to just write custom kernel modules. I also don't remember any hard evidence kdbus was faster than dbus. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sun Mar 27, 2016 3:47 pm Post subject: |
|
|
ICE = In Car Entertainment. At the very least this is covers audio but is starting to cover the like of in-car satnav and video entertainment (back seat). This is where Android is making headway as Google are heading off Apple. Systemd can try to compete for that area but well... Systemd is not a distro and they wod have to compete with Google...
An RTOS is needed not for the ICE but all the car controls instruments, engine control, lighting, electric power steering) and that is why CAN shines. It is a non destructive muti-cast, prioirty driven protocol where arbitration is built into the hardware layer. An RTOS needs to interface with this to pull data from around the car and control aspects of a car. Window/Linux is not fit for this and I am not sure if the safety regs would class a pre-empt+RT patched Linux kernel real-time enough.. If something is flagging it needs to be acted upon there and then, not once something else has finished... _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Mon Mar 28, 2016 1:03 am Post subject: |
|
|
Naib wrote: | ICE = In Car Entertainment. At the very least this is covers audio but is starting to cover the like of in-car satnav and video entertainment (back seat). This is where Android is making headway as Google are heading off Apple. Systemd can try to compete for that area but well... Systemd is not a distro and they wod have to compete with Google...
An RTOS is needed not for the ICE but all the car controls instruments, engine control, lighting, electric power steering) and that is why CAN shines. It is a non destructive muti-cast, prioirty driven protocol where arbitration is built into the hardware layer. An RTOS needs to interface with this to pull data from around the car and control aspects of a car. Window/Linux is not fit for this and I am not sure if the safety regs would class a pre-empt+RT patched Linux kernel real-time enough.. If something is flagging it needs to be acted upon there and then, not once something else has finished... |
IIRC, the way to go with embedded Linux was that the RTOS ran the Linux kernel as a task, preempting it as required. The linux kernel sees only the resources that the RTOS allocates to it. in this way, Linux can be used as a fantastic user interface, but not interfere with the essential control function. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Mon Mar 28, 2016 11:31 am Post subject: |
|
|
Tony0945 wrote: | Naib wrote: | ICE = In Car Entertainment. At the very least this is covers audio but is starting to cover the like of in-car satnav and video entertainment (back seat). This is where Android is making headway as Google are heading off Apple. Systemd can try to compete for that area but well... Systemd is not a distro and they would have to compete with Google...
An RTOS is needed not for the ICE but all the car controls instruments, engine control, lighting, electric power steering) and that is why CAN shines. It is a non destructive muti-cast, priority driven protocol where arbitration is built into the hardware layer. An RTOS needs to interface with this to pull data from around the car and control aspects of a car. Window/Linux is not fit for this and I am not sure if the safety regs would class a pre-empt+RT patched Linux kernel real-time enough.. If something is flagging it needs to be acted upon there and then, not once something else has finished... |
IIRC, the way to go with embedded Linux was that the RTOS ran the Linux kernel as a task, preempting it as required. The linux kernel sees only the resources that the RTOS allocates to it. in this way, Linux can be used as a fantastic user interface, but not interfere with the essential control function. | That's what I said. Whether the RTOS runs linux or RTOS<>Linux bus communications is moot (completely different hardware platforms communicating via some bus would be a lot safer).
Too many people either underestimate or are ignorant of what is involved in getting software certified for flight and automobiles. the Entertainment is just fairy lights. This is why ADA is used heavily and QNX/WindRiver is used.
But that is a digression. Linux is making inroads and one of the early spins with SystemD was "its an init system and it boots fast, perfect for cars"
Forget about the ECU and other control computers (pottering is delusional if he thought linux or systemd would get anywhere near that in the near future...). The ICE is something different and yes linux is perfect for that. The "boot speed" systemd provided might have been a selling point but the thing is
1) systemd + distro would have to compete with Apple and Google as to why their frankenstein is better than iOS or Android ... ESPECIALLY when both of those comes with a navigation software... what navigation software exists for systemd+distro?
2) systemd is no longer an init system. It is a daemon system with an init to boot.
Equally bus1 appears to be pulling the init part out of systemd and thus systemd becomes more of an umbrella entity with common libs linking all (but it isn't monolithic...)
I would like to see how bus1 can do what their limit docu state as bus1 is meant to be a kernel module?
--edit--
yup its got some serious userland parts
http://www.bus1.org/org.bus1.bootstrap.html
so it isn't really a kernel IPC
those associated with Systemd need to stop misrepresenting stuff (did that with the marketing of systemd) and blurring boundaries... Make bus1 kernel IPC... make a device and init system as something that uses DONT mix the two because kernel, init, device are separate things... _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Mar 28, 2016 1:01 pm Post subject: |
|
|
digi_owl wrote: | One of the incentives for kdbus was that car companies had begun adopting Linux for their in-car computing needs, replacing QNX.
Thing is that QNX had a in-kernel RPC bus that behaved somewhat like dbus. So said companies adopted dbus as a replacement. But with dbus sitting in user space, it didn't have the same performance characteristics as what is was replacing. And so the companies started pushing for a in-kernel version of dbus. |
This reads like propaganda. "in-car computing needs" which we've seen only applies to the entertainment system, so is inaccurate by omission. "said companies" with no indication of who they are, but supposedly they're the ones "pushing" for kdbust.
Quote: | What i am speculating is that bus1 is aimed at being a complete solution. A minimal init and device manager, and a in-kernel RPC to tie it all together. |
It seems rather obvious that Lennux is supposed to be "a complete solution" since that is always how it is touted, as the One True Way.
Whereas Linux has always been about choice.
Quote: | That said, the in-kernel RPC stuff of bus1 seems to be protocol agnostic. Thus it would not surprise me if we see the kernel stuff being used without the init stuff (if possible) to speed up dbus. |
Yuck. "protocol-agnostic" from the boys who make everything specific to their one situation.
Also, you seem to have forgotten that dbust is the problem, not a solution.
Shoving it in-kernel will not change the fact that it is a shitty design from martinets who do not know how far out of their depth they are. |
|
Back to top |
|
|
Voltago Advocate
Joined: 02 Sep 2003 Posts: 2593 Location: userland
|
Posted: Mon Mar 28, 2016 1:33 pm Post subject: |
|
|
I can't help but wonder whether this whole systemd/kdbus/buswhatever thing is really just a few misguided high profile devs poettering about, or if it is just a RedHat power grab, plain and simple (and if so, one that has mostly worked thus far). |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3509
|
Posted: Mon Mar 28, 2016 3:52 pm Post subject: |
|
|
Voltago wrote: | I can't help but wonder whether this whole systemd/kdbus/buswhatever thing is really just a few misguided high profile devs poettering about, or if it is just a RedHat power grab, plain and simple (and if so, one that has mostly worked thus far). |
I've expressed the opinion before that some time in the last 5-10 years, Linux became Kewl and attracted a bunch of Windows developers. They found many things in Linux unfamiliar and perhaps discomforting, but rather than learn the new system and culture, they set about "fixing" it - making it more like Windows. The real problem is that as Linux became Kewl, Windows users moved as well, found the same discomfort, and actually prefer the previously mentioned "fixes"
The problem is that the Windows market share is so big, and prior to this Kewl thing, the Linux market share was so small, that it doesn't take many migrating users to swamp the original Linux users. Conquest by demographics, or "Be careful what you wish for - you may get it." When we were wishing for a greater market share for Linux we were really wishing for more Linux users, not for more users who wanted to turn Linux into Windows. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
|