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 ... 10, 11, 12 ... 25, 26, 27  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
bstaletic
Apprentice
Apprentice


Joined: 05 Apr 2014
Posts: 225

PostPosted: Mon Mar 30, 2015 6:04 pm    Post subject: Reply with quote

depontius,

How nice of them! They're going to leave linux users alone and can use they're own systemdOS.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Mon Mar 30, 2015 6:33 pm    Post subject: Reply with quote

It would be for the best if it wasn't a joke.

That would fix all the problems, for those that want they could run Pottering OS
and the rest of us could continue on with the linux we've known for a long time.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1726

PostPosted: Mon Mar 30, 2015 7:17 pm    Post subject: Reply with quote

Hopefully what they will do next, is make it so only Red Hat can use systemd, forcing everyone that wants to use Gnome & systemd has to use Red Hat's distro, so everyone can finally forget about this trash and get on with having a system that actually works.
Back to top
View user's profile Send private message
grot
n00b
n00b


Joined: 17 Dec 2014
Posts: 33

PostPosted: Tue Mar 31, 2015 7:45 am    Post subject: Reply with quote

Phoronix counters that the systemd devs did not actually fork the linux kernel - that Ivan guy is not a systemd developer. http://www.phoronix.com/scan.php?page=news_item&px=Systemd-No-Linux-Fork

I'm curious if there's more to this - how often are mistakes like this made?

rofl - just found this https://github.com/systemdaemon/systemd/issues/1

edit: just saw this link was already put up in the politics of systemd thread
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Tue Mar 31, 2015 9:56 am    Post subject: Reply with quote

http://lkml.iu.edu/hypermail/linux/kernel/1503.3/04981.html
Quote:
In general, there seems to be a number of misconception in this thread
about what kdbus is supposed to be. We're not inventing something new
here with a clean slate, but we're moving parts of an existing
implementation that has tons of users into the kernel, in order to fix
issues that cannot be fixed otherwise in userspace (most notably, the
race gaps that exist when retrieving per-message metadata). Therefore,
we have to keep existing semantics stable, otherwise the exercise is
somewhat pointless.


They simply want to shove the crappy dbus code into the kernel "hoping" that it will make dbus faster.
They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel.

*sigh*
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
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 Mar 31, 2015 4:10 pm    Post subject: Reply with quote

Anon-E-moose wrote:
They simply want to shove the crappy dbus code into the kernel "hoping" that it will make dbus faster.
They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel.

Ah but we're in the world of shifting goalposts, and pretext rather than craft since this is all about "modern" business-methods (and "strategy"), not about delivering great software.

Now the reason it "must" be in kernel is "race gaps that exist when retrieving per-message metadata", which arise from dbus' idiotic implementation in userland, and reimplementing a borked "semantic" that must be preserved even though it flies in the face of all sense. As discussed to death in earlier iterations, including when the networking guys told them five years ago, just to use TIPC.

The simple truth is that Linux already has a much better "kdbus" in-kernel, well-designed and tested for 7 years before it even came near the kernel in 2000.

The sad fact is that the self-styled "kernel experts" who are in fact kernel-rejects and a documentation guy, have no clue about userland programming either, and thus are still trying to "fix" their broken metaphor by pushing it into kernel-space, a la Windoze -- when they should be rethinking their userland lunacy ("because userland can do crazy things, we do all of them.")
The only reason RedHat are pursuing it, is so that dbus GPL-evasion is baked into the kernel, and supported forever more (never to be questioned again.)

After all, they control the userland now, what with the pretty much "industry"-wide capitulation to systemd in bindists. Oh wait. ;)
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6033

PostPosted: Tue Mar 31, 2015 6:12 pm    Post subject: Reply with quote

Anon-E-moose wrote:
They refuse to try and rewrite dbus to make it faster instead hammering on getting dbus-crap into the kernel.

Of course they won't - improving the userspace DBus would give all Unixes an equal playing field, and Redhat is currently trying to murder the competition through tighter and tighter bundling.

Very Microsoft of them.
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Wed Apr 01, 2015 10:08 am    Post subject: Reply with quote

http://lkml.iu.edu/hypermail/linux/kernel/1503.3/06122.html *hmm*

Quote:
I've heard the following use cases for per-connection metadata:

- Authenticating to dbus1 services.

- Identifying connected users for admin diagnostics.

I've heard the following use cases for per-message metadata:

- Logging.

- Authenticating to kdbus services that want this style of authentication.

The only reasonable conclusion I've been able to draw is that the dbus
community intends to use *both* per-connection and per-message
metadata for authentication. This means that, as a general rule,
dropping privileges while you have an open kdbus connection has poorly
defined effects.

It's particularly alarming that, when I express a concern about
logging, the kdbus authors cite authentication as an alternate
justification, and, when I cite a concern about authentication, the
kdbus authors cite logging as an alternative justificaiton.


*chuckle* moving the goal post seems to be the kdbus peoples forte

Quote:
This all feels to me like a total of about four people are going to
understand the tangle that is kdbus security, and that's bad. I think
that the kernel should insist that new security-critical mechanisms
make sense and be hard to misuse. The current design of kdbus, in
contrast, feel like it will be very hard to use correctly.


I don't think they want people (other than themselves) to understand the code.
And of course they have no desire to use it correctly.
It's their wedge to get into the kernel, since Linus has slapped Kay's hand far too often
and they need a way to "bypass" Linus saying "no" to their requests.

I do believe that Linus and others will see this for what it is,
and make them either do the right thing or abandon kdbus completely.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
pjp
Administrator
Administrator


Joined: 16 Apr 2002
Posts: 18165

PostPosted: Thu Apr 02, 2015 2:13 am    Post subject: [split] chaff from kdbus in the kernel Reply with quote

[split] chaff from kdbus in the kernel
_________________
Those who know what's best for us must rise and save us from ourselves.
Back to top
View user's profile Send private message
Shamus397
Apprentice
Apprentice


Joined: 03 Apr 2005
Posts: 218
Location: Ur-th

PostPosted: Fri Apr 10, 2015 4:37 pm    Post subject: Reply with quote

Hrm, looks like it's going in: http://lkml.iu.edu/hypermail/linux/kernel/1503.3/00378.html

If it were me, I'd have it read "if you have an ordinary machine, choose N here"... :P
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7216
Location: Austria

PostPosted: Fri Apr 10, 2015 6:10 pm    Post subject: Reply with quote

That is from two weeks ago, so nothing new just now. kdbus is in linux-next to receive more testing, but that doesn't mean it automatically goes into mainline.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


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

PostPosted: Mon Apr 13, 2015 5:28 am    Post subject: Reply with quote

Yeah nothing to worry about; just keep looking into my eyes, not around the eyes..
After all, it's not like anyone would dream of turning around later and saying "Well you had your chance; no-one responded to the 5th round of sales-pitch, so we put it in, you should have spoken back then" and other variants on "it's all your fault, suckers!"

Just deal with it, move on, etc; all the things we don't do, when we want to make y'all get in line.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7216
Location: Austria

PostPosted: Mon Apr 13, 2015 8:03 am    Post subject: Reply with quote

I was merely preventing the thread from entering a sub-loop duplicating from this comment by repeating what Anon-E-moose had said himself. But if you disagree, go on!
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Mon Apr 13, 2015 9:42 am    Post subject: Reply with quote

I'm still seeing a couple of kernel devs who aren't too thrilled with kdbus as it is at the moment, so I doubt that it will go in until things get hammered out.

And again, just because it's up for review that does not mean automatic inclusion in the kernel
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7216
Location: Austria

PostPosted: Mon Apr 13, 2015 7:22 pm    Post subject: Reply with quote

Now, that happened: https://lkml.org/lkml/2015/4/13/645
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3406

PostPosted: Mon Apr 13, 2015 8:11 pm    Post subject: Reply with quote

genstorm wrote:
Now, that happened: https://lkml.org/lkml/2015/4/13/645


IIRC, it's been in linux-next for less than a month, unless the pull request I saw only a few weeks ago wasn't the first. Does someone really need to look this up?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Mon Apr 13, 2015 10:20 pm    Post subject: Reply with quote

genstorm wrote:
Now, that happened: https://lkml.org/lkml/2015/4/13/645


Reading it now.

Some of the kernel devs don't like kdbus (or the people working on it) much. :lol:

Andy L says
Quote:
Kdbus is very much a port of userspace dbus to the
kernel, and it appears to be a port designed to preserve some
questionable design decisions instead of learning from them.


Pretty much what a lot of us have been saying.
Will see how GKH responds to his critique.


A gem from Andy
Quote:
The fact that some existing userspace does awful things does *not*
justify adding new kernel mechanisms with which to repeat those
mistakes.


He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF)
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3406

PostPosted: Mon Apr 13, 2015 11:38 pm    Post subject: Reply with quote

Anon-E-moose wrote:

A gem from Andy
Quote:
The fact that some existing userspace does awful things does *not*
justify adding new kernel mechanisms with which to repeat those
mistakes.


He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF)


Oh, he's just a hater!

(Some people would take a statement like that seriously, and consider it reason to discount Andy's statement. That's sad.)
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Mon Apr 13, 2015 11:43 pm    Post subject: Reply with quote

depontius wrote:
Anon-E-moose wrote:

A gem from Andy
Quote:
The fact that some existing userspace does awful things does *not*
justify adding new kernel mechanisms with which to repeat those
mistakes.


He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF)


Oh, he's just a hater!

(Some people would take a statement like that seriously, and consider it reason to discount Andy's statement. That's sad.)
this is when the CoC is thrown in his face to dismiss his statement
_________________
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: Tue Apr 14, 2015 3:38 am    Post subject: Reply with quote

Anon-E-moose wrote:
Will see how GKH responds to his critique.

By talking past his points, instead of addressing them, casting aspersions on the "doubter" wrt dodgy benchmarks (ironic when you consider on whom he's casting doubt) and neatly excising the summary and NAK so he can pretend they didn't happen.
Andy Lutomirski wrote:
The fact that some existing userspace does awful things does *not*
justify adding new kernel mechanisms with which to repeat those
mistakes.

Quote:
He's had to tell the kdbus devs this several times and now he's having to tell GKH (WTF)

Kroah-Hartman's approach to dissenting opinion isn't very programmer-like, imo. Thankfully, Lutomirski was having none of it in the mail you quoted:
Quote:
Then I'll have to find a way to embolden my NACK further.
The design is bad, full stop.
(ordering changed)

The only bit that concerns me is where he stated "I generally like the concept of having a better in-kernel IPC mechanism" as it implies he isn't aware of TIPC, nor the previous discussion in 2012, when the networking people advised them to use it.
ie: there already is a better in-kernel IPC mechanism. (cf also: SOCK_RDM.)
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


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

PostPosted: Tue Apr 14, 2015 9:28 am    Post subject: Reply with quote

The biggest thing I've noticed is that some of the kernel devs have mentioned (several times)
that dbus could possibly be speeded up with a look at how it's implemented internally.

The *bus devs have been refusing to do this.

So it's obvious, at least to me, that they want kdbus in the kernel not for any real speedup but for other reason.
And yes, many of them have been brought up in these threads, ie bypassing the gpl, etc.

I doubt that I'm the only one that is seeing things this way.
And we've yet to hear Linus' view on kdbus.
Of course he may be waiting to see if it even makes muster, ie gets past the kernel devs with the NAKs.
_________________
Asus m5a99fx, FX 8320 - nouveau, oss4, rx550 for qemu passthrough
Acer laptop E5-575, i3-7100u - i965, alsa
---both---
5.0.13 zen kernel, profile 17.1 (no-pie & modified) amd64-no-multilib
gcc 8.2.0, eudev, openrc, openbox, palemoon
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3406

PostPosted: Tue Apr 14, 2015 3:31 pm    Post subject: Reply with quote

Greg KH's pull request says kdbus has been in linux-next "for several months". This seems disingenuous to me. A quick check with Google, and it appears that the pull request for linux-next was around March 15, just under one month ago. The initial patches appear to have been first submitted back in October, about six months ago.

All else aside, does anyone know what the "average latency" is for a new large-ish feature to get added to the kernel? Six months from first patch actually seems kind of fast.

To be honest, I (sadly) expect kdbus to go in, maybe on 4.1, maybe on 4.2. I expect the real fireworks to happen when they expect to treat the kernel code with all of the stability of the rest of systemd. Come to think of it, I don't know how stable userspace dbus has been, if it's been more stable than the rest of systemd.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6296

PostPosted: Tue Apr 14, 2015 3:38 pm    Post subject: Reply with quote

depontius wrote:
All else aside, does anyone know what the "average latency" is for a new large-ish feature to get added to the kernel? Six months from first patch actually seems kind of fast.

For unionfs/unionmount/aufs/overlayfs it took about 10-15 years or so - despite being used (and needed to be patched in) by dozens of distributions since many years - I think nobody ever had any doubts that this feature is useful - and still only the most primitive of these (overlayfs) is in the kernal, finally.
Similarly, compression for ext2 took so many years of continuous request that the maintainer finally gave up.
squashfs with lz4 took a year, even after squashfs+lz4 was in the tree.
I never understood, why such useful features needed so many years to become included (I mean: after they have been written and been well-tested).
Then everybody knows how it was with reiser4 which is still not in the kernel, and probably will never be.
Of course behind these, there was not the pressure of money and power.
Back to top
View user's profile Send private message
Naib
Watchman
Watchman


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

PostPosted: Tue Apr 14, 2015 4:07 pm    Post subject: Reply with quote

mv wrote:

I never understood, why such useful features needed so many years to become included (I mean: after they have been written and been well-tested).


Its a very passive way to prove whether what is being requested to be added (till the end of time) is actively being used AND is stable from a userspace point of view.
That has at least been a constant push from the kernel lot - don't break userland. If a kernel module has been around for years AND is being used/depended upon & only the kernel facing API/ABI breaks & is updated then that is a very nice tick.

cgroups was a nice idea but (poorly implemented and now there is talk of a parallel implementation so userland depending on cgroups is not broken...) do we really want that from kdbus which is soo needed applications just do not work
_________________
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: 6296

PostPosted: Tue Apr 14, 2015 6:24 pm    Post subject: Reply with quote

Naib wrote:
That has at least been a constant push from the kernel lot - don't break userland. If a kernel module has been around for years AND is being used/depended upon & only the kernel facing API/ABI breaks & is updated then that is a very nice tick.

Concerning the mentioned filesystems/filesystem features, they satsified all these conditions for many years and nevertheless haven't been included for many years.
Compared to this, I was really surprised how quickly cgroups had been included.
And now seeing something being pushed through, practically untested, actually undesired, when the same thing is already implemented better in the kernel (as SteveL pointed out here, several times) - it is really unbelievable and only explainable through the enormous market power of RedHat.

Edit: Fixed typo in the first sentence which made it not understandable.


Last edited by mv on Wed Apr 15, 2015 1:12 pm; edited 1 time in total
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 ... 10, 11, 12 ... 25, 26, 27  Next
Page 11 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