Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
kdbus in the kernel
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 18, 19, 20 ... 25, 26, 27  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
KuroNeko
n00b
n00b


Joined: 08 Oct 2014
Posts: 23

PostPosted: Fri Jun 19, 2015 6:38 pm    Post subject: Reply with quote

tld wrote:
KuroNeko wrote:
Not sure in which thread this belongs:

http://lists.freedesktop.org/archives/systemd-devel/2015-June/033170.html

Does anyone even have a clue what they're talking about there? None of this is in the kernel at all as yet right? What am I missing?

EDIT: Are they saying that to use the new systemd you have to use kernel patches of theirs?? If so, this while thing's just gone to a new level of absurdity.


As far as I understood, kdbus support is now always built. Systemd will figure out at boot if kdbus is supported on your kernel and use it if it can. You can override the default at compile time or via kernel command line.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3782
Location: Dallas area

PostPosted: Fri Jun 19, 2015 7:16 pm    Post subject: Reply with quote

This is what phoronix says

Quote:
One month after the huge systemd 220 update, systemd 221 is out and primarily geared for fixing bugs.

Lennart Poettering announced the systemd 221 release this morning as a bug-fix release. In addition, systemd 221 now makes sd-bus.h and sd-event.h public and makes KDBUS support no longer optional. KDBUS support is now always built-in rather than offering a compile-time option. KDBUS support can be disabled at runtime if passing the kdbus=0 option to the kernel command-line.

KDBUS as the new in-kernel IPC mechanism remains not yet mainlined as of Linux 4.1. It's not yet clear whether KDBUS will be accepted for the Linux 4.2 kernel, but systemd developers suggest, "We encourage all downstream distributions to begin testing kdbus by adding it to the kernel images in the development distributions, and leaving kdbus support in systemd enabled."


What they're trying to do is get other distros (than RH) to use their kdbus patches against the kernel.

Looks like their attempt at a groundswell support to "force" the kernel devs hands.
I don't think it will work in that respect.
Next up name calling and calls for Linus to step down and let someone "more modern" be the leader. :roll:
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Sat Jun 20, 2015 11:30 am    Post subject: Reply with quote

Quote:
KDBUS support no longer optional. KDBUS support is now always built-in rather than offering a compile-time option. KDBUS support can be disabled at runtime if passing the kdbus=0 option to the kernel command-line.


So, it's both mandatory and optional. Got it.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Jun 20, 2015 1:12 pm    Post subject: Reply with quote

gwr wrote:
So, it's both mandatory and optional. Got it.

Heh "mandatory": it's the new "optional". ;-)
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sat Jun 20, 2015 1:56 pm    Post subject: Reply with quote

Quote:
Torvalds insists that people like Greg Kroah-Hartman have taken over huge parts of the day-to-day work maintaining Linux and that they've built up enough trust to be respected

Does anyone who's followed any of this thread, or the others on systemdbust, think for one second that if the above had happened, say last year, that we wouldn't now be downloading gentoo-sources with kdbust built-in?

Now factor in what Torvalds has said about exactly that code.
Anon-E-moose wrote:
As soon as Linus steps down, "linux" will splinter into more pieces than "unix" ever did.

Looks like it; after all, Greg KH certainly ain't going to stop with his campaign of "niceness" to push kdbust.

He's shown zero awareness of the NAKs based on fundamental design flaws and idiotic usage, in his continued posts, acting as if they never happened and it's just business as usual.

I for one will not be using a kernel led by such a non-coder, only interested in furthering his own position. Classic apparatchik behaviour, no doubt bolstering his stock position in RedHat.

I'll keep a close eye on what people like hpa, Andy Lutomirski, and Russell King(? the ARM guy) get up to, instead. No doubt I'll end up on a "splinter" kernel, which will be mocked as "traditionalist" or some other such specious nonsense.

No way on Earth would I accept GregKH as equivalent to Linus, nor any of the above or several other kernel coders I can think of.

That's not to say a non-coder cannot lead a project; they just have to realise they're an administrator and display humility instead of chutzpah: the exact opposite of this outta-control documentation bod, iow.

Enjoy your corporate overlords when they take over your machine, and don't say you weren't warned.
avx wrote:
IMHO, the biggest threats aren't MS or Apple, it's the companies standing on the shoulders of our long time linux user's work and sh*ttng down our throat.
posted here

Don't forget the Linux Philosophy (thanks, sitquietly) which is what these guys are meant to cherish and nurture.
Back to top
View user's profile Send private message
stephan-t
Tux's lil' helper
Tux's lil' helper


Joined: 12 May 2014
Posts: 118

PostPosted: Sun Jun 21, 2015 2:38 pm    Post subject: Reply with quote

oohhh wait the new kdbus in kernel is optional? and it disable but the systemd developers put into their code and born the sdbus.
I long time ago not watching the systemd developer changes, but its disgusting.
Back to top
View user's profile Send private message
i4dnf
Apprentice
Apprentice


Joined: 18 Sep 2005
Posts: 265
Location: Bucharest, Romania

PostPosted: Sun Jun 21, 2015 3:21 pm    Post subject: Reply with quote

stephan-t wrote:
oohhh wait the new kdbus in kernel is optional?


It is not even in the official kernel tree yet, it exists only as a set of patches. I guess that makes it even more disgusting, no?
_________________
"The only difference between me and a madman is that I am not MAD" (SALVATOR DALI)
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5593
Location: Removed by Neddy

PostPosted: Sun Jun 21, 2015 3:34 pm    Post subject: Reply with quote

stephan-t wrote:
oohhh wait the new kdbus in kernel is optional? and it disable but the systemd developers put into their code and born the sdbus.
I long time ago not watching the systemd developer changes, but its disgusting.
no, that discussion point was posted in the kdbus discussion (this thread) as a "flip of the coin" post between this and the SysD thread.
It is todo with a change in systemd but with ramifications with regards to kdbus



Basically systemd has stated for a long time that they will hard depend on kdbus once it is available (they have also stated they expect lockstep bump of sysd+kernel and they plan to depreciate udev in favour of sd-device)

While the kdbus kernel patch has been worked on sustemd has had support ready for it (its sd-bus).
At a guess it would appear that the systemd lot are getting pissed off that it is taking "too long" to appear in the kernel.
Next approach is the appeal of the masses. Mandate that sd-bus is compiled by systemd is the 1st step - I mean what harm will it do right? There is nothing it can talk to (when has redundant code ever caused any issues...) If you or your distro patch in the present kdbus GREAT systemd will communicate via kdbus instead of dbus (sd-bus talks both) - sd-bus is meant to be a "light weight, OS agnostic wrapper for dbus which can use either libdbus or kdbus"

Next step will be enabling sd-device and completely depreciating udev - non systd distro will have to make a decision to either go to systd or use eudev (or static dev -libudev is being used by userland apps tho...)

The existence of sd-device will more than likely demand kdbus as how can the init system talk to the device manager if udev service isnt started"

Again forcing distro that have committed to systemd to now commit to sd-device and thus sd-bus via kdbus.

Finally by shear inertia and pressure from other distros in the managing of such a key patchset outside of the tree a head-on conflict will erupt and the threat of taking the kernel away (ffmpeg-libav saga and ignoring the other exists) or it is merged in in whatever state it is.

The kernel devs need to be VERY careful. Stay clearly objective and technical and ignore any borderline soft personal attack as any hostile personal response will just provide the platform to justify becoming the one true fork

It is a gamble by the sysd (RedHat) lot and I am not sure if they are completely ignorant of game theory or are very VERY aware of it and are setting up an end-game situation - worst-case for them is they roll back their goals with the sysd project), ie their win-win situation is golden and their lose-lose is becoming less and less likely & less of a driver into obscurity
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jun 21, 2015 4:44 pm    Post subject: Reply with quote

Naib wrote:
Basically systemd has stated for a long time that they will hard depend on kdbus once it is available (they have also stated they expect lockstep bump of sysd+kernel and they plan to depreciate udev in favour of sd-device)

Sorry to be pedantic, but the word you're looking for is "deprecate"; depreciation is a specific term, and means: the loss in value of a financial asset over time. See how odd this reads when you hold that thought in your head:
Quote:
Next step will be enabling sd-device and completely depreciating udev - non systd distro will have to make a decision to either go to systd or use eudev (or static dev -libudev is being used by userland apps tho...)

The existence of sd-device will more than likely demand kdbus as how can the init system talk to the device manager if udev service isnt started"
Again forcing distro that have committed to systemd to now commit to sd-device and thus sd-bus via kdbus.

Finally by sheer inertia and pressure from other distros in the managing of such a key patchset outside of the tree a head-on conflict will erupt and the threat of taking the kernel away (ffmpeg-libav saga and ignoring the other exists) or it is merged in in whatever state it is.

Any distro that's dumb enough not to jump ship to eudev, deserves whatever they get, afaic.
They're just middle-men, looking to profit from whatever seems easiest; not much different from most Windows OEMs, imo.

If they had half a brain, they'd realise there's not much profit in being one of 20 fedora-clones.
No doubt they think they can survive as a "brand" because they're led by numpties with an MBA and not much else.

The problem with sd-bust is what you said: it's a wrapper for the existing crappy design; kdbust is going in to Lennux without any of the design flaws even acknowledged, let alone resolved.

The thing I find amazing is that they get all this review for free, with everything explained to them, and they still don't listen.
Which indicates, as if we didn't already know, that this is not about delivering the best solutions, but a business-war of propaganda and politicking designed to land-grab Linux for the rest of time.
After all, Torvalds is only human, and soon enough he won't want to do much beyond see his grandchildren.

That is the prize that RedHat is going for: control of a codebase that no corporation nor conglomerate, could ever develop.

That's why the VCs gave stock options to kernel devs in the 90s: to keep them on side (or at least: conflicted) for the long game.
Quote:
It is a gamble by the sysd (RedHat) lot and I am not sure if they are completely ignorant of game theory or are very VERY aware of it and are setting up an end-game situation - worst-case for them is they roll back their goals with the sysd project), ie their win-win situation is golden and their lose-lose is becoming less and less likely & less of a driver into obscurity

They're part of a huge conglomerate now: obscurity is not a concern, only the profit margin. You're right though: the win-win is golden for them, and shitty for everyone else, just like Microsoft killed the truly-independent PC software business.
"You want to compete with us? But we're your only supplier."

If people haven't realised that this is vendor lock-in, pure and simple, then they are as dumb as they want to be.

I'd much rather use Linux as Torvalds intended.

In the meantime, there's no point beating ourselves up about the gullibility of the madding crowd.
In 15 or 20 years, another "One True Way" is going to come round again, after a decade or so where systemd is considered an embarrassment, then simply forgotten as if it never happened, since that's how humans usually handle their mistakes.

By then whichever division of RedHat is managing Poeterring will no doubt have depreciated to zero ;) but no-one will care, as it's just part of the background, and sheeple are more interested in kewl desktop effects than functional software. "Look, shiny!"
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3782
Location: Dallas area

PostPosted: Tue Jun 23, 2015 9:39 am    Post subject: Reply with quote

From lkml (Andy Lutomirski) http://lkml.iu.edu/hypermail/linux/kernel/1506.2/04853.html

Quote:
Hi Linus,

Can you opine as to whether you think that kdbus should be merged? I
don't mean whether you'd accept a pull request that Greg may or may
not send during this merge window -- I mean whether you think that
kdbus should be merged if it had appropriate review and people were
okay with the implementation.

The current state of uncertainty is problematic, I think. The kdbus
team is spending a lot of time making things compatible with kdbus,
and the latest systemd release makes kdbus userspace support
mandatory. The kernel people who would review it (myself included)
probably don't want to review new versions at a line-by-line level,
because we (myself included) either don't know whether there's any
point or don't think that it should be merged *even if the
implementation were flawless*.

For my part, here's my argument why the answer should be "no, kdbus
shouldn't be merged":
...
In summary, I think that a very high quality implementation of the
kdbus concept and API would be a bit faster than a very high quality
userspace implementation of dbus. Other than that, I think it would
actually be worse. The kdbus proponents seem to be comparing the
current kdbus implementation to the current userspace implementation,
and a favorable comparison there is not a good reason to merge it.

--Andy

[1] I spent a while today trying to benchmark sd-bus. I gave up,
because I couldn't get test code to build. I don't have the patience
to try harder.


Hmm

Edit to add: A/o right now there are only about 5 posts in this particular "subject" including one from GKH.
Worth a read.
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5593
Location: Removed by Neddy

PostPosted: Tue Jun 23, 2015 9:56 am    Post subject: Reply with quote

http://lkml.iu.edu/hypermail/linux/kernel/1506.2/04860.html
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Tue Jun 23, 2015 3:03 pm    Post subject: Reply with quote

I think this is getting a bit silly for the kernel devs, and I can't blame them for this inquiry. GKH has essentially side-stepped every single question and concern raised by them, and patches and pull requests continue to come in for code that is still rapidly changing. Meanwhile, it appears RH has the effort to spend shimming around the kernel rather than spending the effort to fix dbus or address any kernel issues. Why would any kernel dev _want_ to spend the time reviewing something that doesn't get addressed? GKH is being disingenuous at best.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Tue Jun 23, 2015 6:20 pm    Post subject: Reply with quote

gwr wrote:
GKH has essentially side-stepped every single question and concern raised by them, and patches and pull requests continue to come in for code that is still rapidly changing. Meanwhile, it appears RH has the effort to spend shimming around the kernel rather than spending the effort to fix dbus or address any kernel issues. Why would any kernel dev _want_ to spend the time reviewing something that doesn't get addressed?

Precisely; the whole thing is a giant waste of time. It's a bad design, period.

Everyone with any sort of experience who's reviewed it along the way, has said the same thing.

The response has without fail been to simply ignore whomever it was, and keep up the propaganda and arm-twisting campaign.

Lot harder to do when Torvalds has come out and flat-out labelled dbust "bad userspace code", which is shorthand for "this is bad userspace code and design, so there's no point in trying to optimise it, nor support its usage mode in the kernel."
It's always better for userland beginners to learn the proper facilities, for everyone concerned.

It used to come up a lot, less so nowadays since we've had 20 years of people learning in public, with mistakes there for others to learn from, or discussion to refer back to.

OFC that's not in play, when you have outsiders (like Windoze rejects) invading the community in order to make a name and a buck; they don't care about the traditions, and they don't care about the craft, only in getting themselves ahead at the expense of everyone else.
Quote:
GKH is being disingenuous at best.

It's odd, I feel a vague sense of relief reading his bitchiness. He's carried on like that with me in the past, and I know it's wrong, but I feel almost glad that it's not just me. I think it's more that I can see it as bitchiness, plain and simple, when it's not directed at me.
That in itself makes me realise, that it wasn't my problem; independent verification if you like.

It does give the lie to his default posture of "friendly big-brother, who you really do want in charge (look: how smug^W confident I sound, I must be right..)" Like most apparatchiks, he knows what line to sell, but scratch the surface by disagreeing, which is seen as hostile opposition as you're getting in his way, and he has a right to advance, goddammit.. and you get the snipey put-downs, to make an example of you so others will be cowed.
It's pure bully-boy behaviour, imo.

This is just pathetic:
GregK-H wrote:
How about you just wait for the real merge request to be submitted, and
we can go from there. Perhaps I wasn't going to do it this release?
Perhaps I was? Who knows? Who cares.

Perhaps you could be a bit more collaborative, rather than assuming everyone just has to fall in line whenever you breezily feel to drop a shedload of crappy code into the kernel.

Does anyone really want such an attitude in charge of kernel-development when Torvalds steps back from the daily grind?
If so, expect the quality to nosedive, as the Red Queen lays about her, whilst all the real coders move on to something else (like the "hater's fork".)
Quote:
> The current state of uncertainty is problematic, I think. The kdbus
> team is spending a lot of time making things compatible with kdbus,
> and the latest systemd release makes kdbus userspace support
> mandatory.

I stopped here in this email, as this is just flat out totally wrong,
and I don't want to waste my time trying to refute other totally wrong
statements as that would just somehow give them some validation that
they could possibly be correct.

More weasel words; systemdbust clearly makes the userspace support compile by default, and we've all seen exactly what their "you can turn it off with a compile-time switch" really means: "if you turn this off, we'll conduct a campaign of vilification against you" which no-one in their right mind wants to deal with.

Life's far too short to devote headspace to working with such asshole numpties.

They're foisting it on to downstream bindists as they've foisted everything else for the last 7-10 years.
Anyone who wants to argue different is either hopelessly naive or a liar, afaic.

No-one gave them any trouble when they told us partitioning schemes that have been in use for over 30 years, are "broken by design", nor when they dicked about with races they introduced, should have foreseen, and never bothered to test; instead they got away with the insanity of hw bus names exposed to the admin, as well as the bulshytt ride that is loginkit.

There's "crazy userland", and then there's "desktop": where any old shit will do, so long as it looks pretty. After all, "the kernel will stop us doing anything dangerous, right?" Not any more: not with all that insanity on top of it. That's what PAM is for, but you drowned that in polkit-js-systemdbust-login too.

That's the trouble with business led by sales and marketing: it's not about getting the job done any more, it's all about the hype and the sizzle, not the sausage. You can keep it.
Back to top
View user's profile Send private message
augustin
Guru
Guru


Joined: 23 Feb 2015
Posts: 318

PostPosted: Wed Jun 24, 2015 1:29 am    Post subject: Reply with quote

Quote:
> Can you opine as to whether you think that kdbus should be merged? I
> don't mean whether you'd accept a pull request that Greg may or may
> not send during this merge window -- I mean whether you think that
> kdbus should be merged if it had appropriate review and people were
> okay with the implementation.

So I am still expecting to merge it, mainly for a rather simple
reason: I trust my submaintainers, and Greg in particular. So when a
major submaintainer wants to merge something, that pulls a *lot* of
weight with me.

That said, I have to admit to being particularly disappointed with the
performance argument for merging it. Having looked at the dbus
performance, and come to the conclusion that the reason dbus performs
abysmally badly is just pure shit user space code, I am not AT ALL
impressed by the performance argument. We don't merge kernel code just
because user space was written by a retarded monkey on crack. Kernel
code has higher standards, and yes, that also means that it tends to
perform better, but no, "user space code is shit" is not a valid
reason for pushing things into the kernel.

So quite frankly, the "better performance" argument is bogus in my opinion.

That still leaves other arguments, but it does weaken the case for
kdbus quite a bit.

Because go out and read pretty much any argument for kdbus, and the
*first* argument is always performance. The articles never say "..
because the user-space dbus code is crap", though.

Linus

http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05492.html
Back to top
View user's profile Send private message
Yamakuzure
Advocate
Advocate


Joined: 21 Jun 2006
Posts: 2273
Location: Bardowick, Germany

PostPosted: Wed Jun 24, 2015 8:02 am    Post subject: Reply with quote

Linus Torvalds wrote:
We don't merge kernel code just because user space was written by a retarded monkey on crack.
Hear hear! ;-)
Andy Lutomirski wrote:
I don't intend to review that part for security in advance because I've already said my part: I think the design is unfit for its purpose. Given that I don't see how one is supposed to use it in a sensible manner for sandboxing in the first place, it's hard to evaluate whether it will do its job a priori.
From his answer to Linus.
_________________
Important German:
  1. "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
  2. "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 3782
Location: Dallas area

PostPosted: Wed Jun 24, 2015 9:52 am    Post subject: Reply with quote

This was posted by Ingo (in response to the post that augustin quoted)

Quote:
Beyond the cons, I see four arguments in favor of kdbus:

- In its current form kdbus really does not hurt the core kernel in any appreciable
way: like Android's Binder it sits in its own corner that doesn't hurt anyone.


http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00073.html

Interesting reasoning on his part.

As far as Linus trusting GKH, I think Linus will look back (sometime in the future) and realize what a horrible mistake he made in doing so.

For me, I won't have k(dbus) on my system as it works perfectly well without it.
And if it should somehow become mandatory to even use linux, then I see a bsd variant in my future.
I don't need the political crap nor devs, ie GKH, selling out the majority of linux users just for some goodies that they will get from RH (or whoever).
_________________
Asus m5a99fx, FX 8320 - nouveau & radeon, oss4
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.0 (no-pie) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Wed Jun 24, 2015 11:02 am    Post subject: Reply with quote

Anon-E-moose wrote:


Interesting reasoning on his part.



It's true if you only look at the situation from the kernel's perspective. It doesn't hurt the kernel, it hurts some of the Linux-based distributions that use it. I don't share that point of view, because it's a bit like biting the hand that feeds you.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5593
Location: Removed by Neddy

PostPosted: Wed Jun 24, 2015 11:35 am    Post subject: Reply with quote

Anon-E-moose wrote:
This was posted by Ingo (in response to the post that augustin quoted)

Quote:
Beyond the cons, I see four arguments in favor of kdbus:

- In its current form kdbus really does not hurt the core kernel in any appreciable
way: like Android's Binder it sits in its own corner that doesn't hurt anyone.


http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00073.html

Interesting reasoning on his part.

As far as Linus trusting GKH, I think Linus will look back (sometime in the future) and realize what a horrible mistake he made in doing so.

For me, I won't have k(dbus) on my system as it works perfectly well without it.
And if it should somehow become mandatory to even use linux, then I see a bsd variant in my future.
I don't need the political crap nor devs, ie GKH, selling out the majority of linux users just for some goodies that they will get from RH (or whoever).


Thats a very top-level view of kdbus "it sits in its own corner" and if it did then sure, why not...
If KDBUS really was just a bolt on then the kernel developers remaining as independent from wider distribution political battles would find it hard to not accept the concern (assume KDBUS was from a kernel point of view, good code... what argument exists to reject it, atomic to the kernel?)
Which comes back to the present implementation that spreads its fingers across alot of kernel functions -ie isn't just in its own little corner and the reasoning being "faster" faster isn't itself a good reason (Windows kernel put font rendering into the kernel and it resulted in an exploit from a webpage...). The argument for its inclusion will more than likely morph from one of performance to one of security in association with sd-bus & sd-devices, which then ties up a very specific boot sequence for linux at the point of init handover...
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Wed Jun 24, 2015 11:42 am    Post subject: Reply with quote

Naib wrote:
... which then ties up a very specific boot sequence for linux at the point of init handover...


But, apparently according to Linus' reasoning, that isn't a kernel issue.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5593
Location: Removed by Neddy

PostPosted: Wed Jun 24, 2015 11:58 am    Post subject: Reply with quote

and he has a point when viewing linux as a kernel.
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
gwr
Apprentice
Apprentice


Joined: 19 Nov 2014
Posts: 194

PostPosted: Wed Jun 24, 2015 12:03 pm    Post subject: Reply with quote

Naib wrote:
and he has a point when viewing linux as a kernel.


Although, it's still confusing to me that Linus views putting it in the kernel for "performance reasons" to be invalid. If kdbus really does only occupy a corner of the kernel and it's up to distributions to decide whether to use it or not, why would he care if the performance was utter crap? Why pick on that criteria, and not, oh, I dunno, that the entire design is bafflingly pointless?
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1371

PostPosted: Thu Jun 25, 2015 1:17 am    Post subject: Reply with quote

gwr wrote:
Although, it's still confusing to me that Linus views putting it in the kernel for "performance reasons" to be invalid.
He did say he would like to have a better performing kdbus in the kernel. As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment. But perhaps Linus heard it through the grapevine there is potential to make performance of kdbus better. Linus has some interest in kdbus, because a sanely programmed kdbus in Linux mainline kernel has some benefits:

- boot and shutdown with systemd in a sober manner without all these special hardcoded units
- the widely and since long used dbus will run in a secured kdbus environment (without javascript)
- virtual machines communication feature added
- dbus running in the kdbus environment will scale up for use with multimedia

The last one is possible due to less mem copying using dbus in a kdbus environment, which was the point people talked about performance. Most of the above would be used by the majority of Linux users from day one. Also the adoption rate of application programmers will boom, because dbus protocols do hide complexity. If all of the security problems of dbus can be solved in the kernel the rate of security issues of new applications will go down. And for sure the argument of steveL: To be able to circumvent the GPL will push Linux as a choosen environment for applications.

Andy Lutomirski announcing how he will test the next kdbus proposal regarding security and Linus interest in performance, which signals an important aspect of quality of the code, makes me confident the kernel developers are able to decide when to include kdbus into mainline. Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid.
_________________
fun2gen2
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


Joined: 21 May 2004
Posts: 5593
Location: Removed by Neddy

PostPosted: Thu Jun 25, 2015 6:53 am    Post subject: Reply with quote

They are stupid, how many pull request have there been before ? How many times did they change the API
_________________
The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6277

PostPosted: Thu Jun 25, 2015 6:54 am    Post subject: Reply with quote

ulenrich wrote:
Linus has some interest in kdbus, because a sanely programmed kdbus in Linux mainline kernel has some benefits

It is very dirty rhetoric trick to formulate marketing buzzwords pretending that they were from Linus.

Linus said very precisely his only reason why he does not kill the kdbus idea immediately: He had previously trusted one person advocating it.

This is a valid social reason. Quite the opposite of your invented marketing reasons which BTW are technically plainly false. (Except for the last one which is exactly the argument which Linus explicitly rejected as invalid.)

Edit: removed a too aggressive formulation.


Last edited by mv on Thu Jun 25, 2015 11:22 am; edited 1 time in total
Back to top
View user's profile Send private message
augustin
Guru
Guru


Joined: 23 Feb 2015
Posts: 318

PostPosted: Thu Jun 25, 2015 7:35 am    Post subject: Reply with quote

ulenrich wrote:
gwr wrote:
Although, it's still confusing to me that Linus views putting it in the kernel for "performance reasons" to be invalid.
He did say he would like to have a better performing kdbus in the kernel. As performance issues signal bad quality of code this is a valid argument to reject kdbus at this moment. But perhaps Linus heard it through the grapevine there is potential to make performance of kdbus better. Linus has some interest in kdbus, because a sanely programmed kdbus in Linux mainline kernel has some benefits:

- boot and shutdown with systemd in a sober manner without all these special hardcoded units
- the widely and since long used dbus will run in a secured kdbus environment (without javascript)
- virtual machines communication feature added
- dbus running in the kdbus environment will scale up for use with multimedia

The last one is possible due to less mem copying using dbus in a kdbus environment, which was the point people talked about performance. Most of the above would be used by the majority of Linux users from day one. Also the adoption rate of application programmers will boom, because dbus protocols do hide complexity. If all of the security problems of dbus can be solved in the kernel the rate of security issues of new applications will go down. And for sure the argument of steveL: To be able to circumvent the GPL will push Linux as a choosen environment for applications.

Andy Lutomirski announcing how he will test the next kdbus proposal regarding security and Linus interest in performance, which signals an important aspect of quality of the code, makes me confident the kernel developers are able to decide when to include kdbus into mainline. Any push using money in a corrupted way would hurt the monetary interests of all the Linux corporations in the longer run. Do not think these guys are bloody stupid.


I am still trying to get up to speed. Is systemd the main/only motivation to include kdbus into the kernel (besides GPL circumnavigation, as pointed out by Steve, I believe)?

What is the primary motivation for the people behind kdbus?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3 ... 18, 19, 20 ... 25, 26, 27  Next
Page 19 of 27

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum