Hi
On Tue, Apr 21, 2015 at 2:20 PM, Michal Hocko wrote:
> On Tue 21-04-15 12:17:49, David Herrmann wrote:
>> Hi
>>
>> On Tue, Apr 21, 2015 at 11:35 AM, One Thousand Gnomes
>> wrote:
>> >> On top of that, I think that someone into resource management needs to
>> >> seriously consider whether
On Tue, Apr 21, 2015 at 03:18:35PM +0200, Olivier Galibert wrote:
> On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman
> wrote:
> > Bringing up SCM_RIGHTS means that this is not going to be a bus system
> > at all. One principal design goal is to _not_ have peer-to-peer
> > connections between
Hi,
On Tue, Apr 21, 2015 at 5:07 AM, Johannes Stezenbach wrote:
> My line of thinking had been to amend DBus with optional direct
> client/server communication for the performance critical
> cases, since I believe those cases are RPC calls and not other
> types of messaging (see also the
On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman
wrote:
> Bringing up SCM_RIGHTS means that this is not going to be a bus system
> at all. One principal design goal is to _not_ have peer-to-peer
> connections between all communicating parties, but rather one connection
> to a central
On Tue, Apr 21, 2015 at 01:03:59PM +0200, Jiri Kosina wrote:
> On Tue, 21 Apr 2015, Greg Kroah-Hartman wrote:
>
> > > We do need something for the multicast messaging. Whether that's
> > > supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX
> > > message queue extensions ?).
On Tue 21-04-15 12:17:49, David Herrmann wrote:
> Hi
>
> On Tue, Apr 21, 2015 at 11:35 AM, One Thousand Gnomes
> wrote:
> >> On top of that, I think that someone into resource management needs to
> >> seriously consider whether having a broadcast send do get_user_pages
> >> or the equivalent on
On 2015-04-20 16:26, George Spelvin wrote:
It's used everywhere, on servers,
embedded systems, desktops, you name it. All languages have bindings
for it, and it's the underpinning of a modern Linux stack.
Since when? D-bus is some GUI depoendency. On my console-only servers, it's
not
On Tue, Apr 21, 2015 at 01:09:42PM +0200, Greg Kroah-Hartman wrote:
> Vs. being offensive quickly like you started out with? :)
Of course you'll come back with an attack. Polemical tactics or what is
this called?
> And I've kept asking for review, and the people who have reviewed it,
> their
On Tue, Apr 21, 2015 at 12:53:20PM +0200, Borislav Petkov wrote:
> On Tue, Apr 21, 2015 at 12:31:28PM +0200, Greg Kroah-Hartman wrote:
> > "Your code is too large" does not provide any value to this discussion
> > at all, sorry. Richard is being a jerk here, please don't perpetuate
> > that line
On Tue, 21 Apr 2015, Greg Kroah-Hartman wrote:
> > We do need something for the multicast messaging. Whether that's
> > supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX
> > message queue extensions ?). There's no real IP layer reliable ordered
> > multicast delivery system
On Tue, Apr 21, 2015 at 12:31:28PM +0200, Greg Kroah-Hartman wrote:
> "Your code is too large" does not provide any value to this discussion
> at all, sorry. Richard is being a jerk here, please don't perpetuate
> that line of discussion, it's not helpful at all.
We're becomint offensive slowly,
On Tue, Apr 21, 2015 at 10:35:19AM +0100, One Thousand Gnomes wrote:
>
> We do need something for the multicast messaging. Whether that's
> supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX
> message queue extensions ?). There's no real IP layer reliable ordered
> multicast
On Mon, Apr 20, 2015 at 03:06:09PM -0700, Andy Lutomirski wrote:
> On Mon, Apr 20, 2015 at 2:46 PM, Greg Kroah-Hartman
> wrote:
> > On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
> >> Greg,
> >>
> >> Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
> >> >> In which
Hi
On Tue, Apr 21, 2015 at 11:35 AM, One Thousand Gnomes
wrote:
>> On top of that, I think that someone into resource management needs to
>> seriously consider whether having a broadcast send do get_user_pages
>> or the equivalent on pages supplied by untrusted recipients (plural!)
>> is a good
> On top of that, I think that someone into resource management needs to
> seriously consider whether having a broadcast send do get_user_pages
> or the equivalent on pages supplied by untrusted recipients (plural!)
> is a good idea.
Oh but its so much fun if you pass pages belonging to a device
On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
> Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
> >> In which situation on a common Linux system is the current dbus too slow
> >> today?
> >> I've never seen a issue like "Oh my system is slow because dbus is
> >> eating
On Mon, Apr 20, 2015 at 11:46:51PM +0200, Greg Kroah-Hartman wrote:
> As was pointed out, even the tiny IoT devices running Linux are now
> using D-Bus, it's everywhere :)
I would like to take issue with that assertion. Some people are
putting dbus and systemd into embedded devices, but not into
Hi,
On 04/20/2015 08:01 PM, James Bottomley wrote:
> On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote:
>> Do you have ideas on how to go about fixing it, whether in userspace
>> or kernel dbus?
>
> Well, I've always suspected the solution would be for dbus to have a
> hierarchical
On Mon, Apr 20, 2015 at 03:06:09PM -0700, Andy Lutomirski wrote:
>
> I do. Implement something like my old SCM_IDENTITY proposal, which is
> kind of like kdbus metadata, opt-in, over UNIX sockets. Except that I
> never proposed most of the absurd metadata items that kdbus is
> proposing, and I
I'm not exactly sure what the problem is. It might not even be a
problem with D-bus, and it's probably a timeout issue as you said.
I'll give kdbus a try anyway and report back.
Thanks,
Diego
On Tue, Apr 21, 2015 at 2:06 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Tue, Apr 21,
On Tue, Apr 21, 2015 at 7:27 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 21-04-15 16:01:01, David Herrmann wrote:
Hi
On Tue, Apr 21, 2015 at 2:20 PM, Michal Hocko mho...@suse.cz wrote:
On Tue 21-04-15 12:17:49, David Herrmann wrote:
Hi
On Tue, Apr 21, 2015 at 11:35 AM, One Thousand
On Tue, Apr 21, 2015 at 3:31 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Mon, Apr 20, 2015 at 03:06:09PM -0700, Andy Lutomirski wrote:
On Mon, Apr 20, 2015 at 2:46 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard
On Tue, Apr 21, 2015 at 1:09 AM, Daniel Mack dan...@zonque.org wrote:
Hi,
On 04/20/2015 08:01 PM, James Bottomley wrote:
On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote:
Do you have ideas on how to go about fixing it, whether in userspace
or kernel dbus?
Well, I've always
On Tue, Apr 21, 2015 at 11:36:54AM -0500, Eric W. Biederman wrote:
HeHeHe. You mean all I need to do to get around all of the logging servers is
capture CAP_SYS_BOOT? Say like just capture this crazy watchdog program
that doesn't run as root so that it can only reboot the system? HeHeHe
So
On Tue, Apr 21, 2015 at 01:03:59PM +0200, Jiri Kosina wrote:
On Tue, 21 Apr 2015, Greg Kroah-Hartman wrote:
We do need something for the multicast messaging. Whether that's
supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX
message queue extensions ?). There's no
On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
Bringing up SCM_RIGHTS means that this is not going to be a bus system
at all. One principal design goal is to _not_ have peer-to-peer
connections between all communicating parties, but rather one connection
On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
In which situation on a common Linux system is the current dbus too slow
today?
I've never seen a issue like Oh my system is slow because dbus is
eating too much CPU
On Mon, Apr 20, 2015 at 03:06:09PM -0700, Andy Lutomirski wrote:
I do. Implement something like my old SCM_IDENTITY proposal, which is
kind of like kdbus metadata, opt-in, over UNIX sockets. Except that I
never proposed most of the absurd metadata items that kdbus is
proposing, and I also
Hi
On Tue, Apr 21, 2015 at 11:35 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
On top of that, I think that someone into resource management needs to
seriously consider whether having a broadcast send do get_user_pages
or the equivalent on pages supplied by untrusted recipients
On top of that, I think that someone into resource management needs to
seriously consider whether having a broadcast send do get_user_pages
or the equivalent on pages supplied by untrusted recipients (plural!)
is a good idea.
Oh but its so much fun if you pass pages belonging to a device
Hi,
On 04/20/2015 08:01 PM, James Bottomley wrote:
On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote:
Do you have ideas on how to go about fixing it, whether in userspace
or kernel dbus?
Well, I've always suspected the solution would be for dbus to have a
hierarchical namespace of
On Mon, Apr 20, 2015 at 11:46:51PM +0200, Greg Kroah-Hartman wrote:
As was pointed out, even the tiny IoT devices running Linux are now
using D-Bus, it's everywhere :)
I would like to take issue with that assertion. Some people are
putting dbus and systemd into embedded devices, but not into
Hi
On Tue, Apr 21, 2015 at 4:27 PM, Michal Hocko mho...@suse.cz wrote:
On Tue 21-04-15 16:01:01, David Herrmann wrote:
On Tue, Apr 21, 2015 at 2:20 PM, Michal Hocko mho...@suse.cz wrote:
If for nothing else then the memcg reasons mentioned in
other email
Hi
On Tue, Apr 21, 2015 at 2:20 PM, Michal Hocko mho...@suse.cz wrote:
On Tue 21-04-15 12:17:49, David Herrmann wrote:
Hi
On Tue, Apr 21, 2015 at 11:35 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
On top of that, I think that someone into resource management needs to
On Tue 21-04-15 16:01:01, David Herrmann wrote:
Hi
On Tue, Apr 21, 2015 at 2:20 PM, Michal Hocko mho...@suse.cz wrote:
On Tue 21-04-15 12:17:49, David Herrmann wrote:
Hi
On Tue, Apr 21, 2015 at 11:35 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
On top of that, I think
Hi,
On Tue, Apr 21, 2015 at 5:07 AM, Johannes Stezenbach j...@sig21.net wrote:
My line of thinking had been to amend DBus with optional direct
client/server communication for the performance critical
cases, since I believe those cases are RPC calls and not other
types of messaging (see also
On Tue, Apr 21, 2015 at 03:18:35PM +0200, Olivier Galibert wrote:
On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
Bringing up SCM_RIGHTS means that this is not going to be a bus system
at all. One principal design goal is to _not_ have peer-to-peer
On Tue 21-04-15 12:17:49, David Herrmann wrote:
Hi
On Tue, Apr 21, 2015 at 11:35 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
On top of that, I think that someone into resource management needs to
seriously consider whether having a broadcast send do get_user_pages
or the
On 2015-04-20 16:26, George Spelvin wrote:
It's used everywhere, on servers,
embedded systems, desktops, you name it. All languages have bindings
for it, and it's the underpinning of a modern Linux stack.
Since when? D-bus is some GUI depoendency. On my console-only servers, it's
not
Um, no, they go through the kernel for that model as well, same
interface, it just depends on the type of message that you are sending
as to who the recipients are (single or more than one.)
In other words its bog standard classic network layer multicasting. You
don't need much policy for that
On 2015-04-21 15:38, Matthew Garrett wrote:
On Tue, Apr 21, 2015 at 11:36:54AM -0500, Eric W. Biederman wrote:
HeHeHe. You mean all I need to do to get around all of the logging servers is
capture CAP_SYS_BOOT? Say like just capture this crazy watchdog program
that doesn't run as root so
Hi all!
On Die, 2015-04-21 at 09:37 -0400, Havoc Pennington wrote:
[...]
This has long been sort of the 'party line' and I've told many people
this on the dbus mailing list over the years (almost exactly what you
just said - that for performance-critical cases they should open a
direct socket
On Tue, Apr 21, 2015 at 9:51 PM, Bernd Petrovitsch
be...@petrovitsch.priv.at wrote:
Hi all!
On Die, 2015-04-21 at 09:37 -0400, Havoc Pennington wrote:
[...]
This has long been sort of the 'party line' and I've told many people
this on the dbus mailing list over the years (almost exactly what
On Tue, Apr 21, 2015 at 10:35:19AM +0100, One Thousand Gnomes wrote:
We do need something for the multicast messaging. Whether that's
supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX
message queue extensions ?). There's no real IP layer reliable ordered
multicast
On Tue, Apr 21, 2015 at 12:31:28PM +0200, Greg Kroah-Hartman wrote:
Your code is too large does not provide any value to this discussion
at all, sorry. Richard is being a jerk here, please don't perpetuate
that line of discussion, it's not helpful at all.
We're becomint offensive slowly,
On Tue, 21 Apr 2015, Greg Kroah-Hartman wrote:
We do need something for the multicast messaging. Whether that's
supporting AF_LOCAL, SOCK_RDP with multicast or something else (POSIX
message queue extensions ?). There's no real IP layer reliable ordered
multicast delivery system that is
On Tue, Apr 21, 2015 at 12:53:20PM +0200, Borislav Petkov wrote:
On Tue, Apr 21, 2015 at 12:31:28PM +0200, Greg Kroah-Hartman wrote:
Your code is too large does not provide any value to this discussion
at all, sorry. Richard is being a jerk here, please don't perpetuate
that line of
On Mon, Apr 20, 2015 at 03:06:09PM -0700, Andy Lutomirski wrote:
On Mon, Apr 20, 2015 at 2:46 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
Greg,
Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
In which
On Tue, Apr 21, 2015 at 01:09:42PM +0200, Greg Kroah-Hartman wrote:
Vs. being offensive quickly like you started out with? :)
Of course you'll come back with an attack. Polemical tactics or what is
this called?
And I've kept asking for review, and the people who have reviewed it,
their
I'd like to see D-Bus in the kernel (kdbus), if that's going to make
D-Bus faster.
See this application taking 15 seconds to start just because D-Bus is too slow.
https://bugs.kde.org/show_bug.cgi?id=342682
Hopefully kdbus solves problems such as this one.
Diego
On Wed, Apr 15, 2015 at 2:59
On Tue, Apr 21, 2015 at 01:54:54PM -0300, Diego Viola wrote:
I'd like to see D-Bus in the kernel (kdbus), if that's going to make
D-Bus faster.
See this application taking 15 seconds to start just because D-Bus is too
slow.
https://bugs.kde.org/show_bug.cgi?id=342682
Hopefully kdbus
Tom Gundersen t...@jklm.no writes:
Moreover, the daemon performing the shutdown tasks is necessarily
always privileged enough to do so, so calling into the kernel and see
what happens is completely the wrong thing to do (it would simply
succeed). What matters is if the client calling the
On Mon, Apr 20, 2015 at 2:46 PM, Greg Kroah-Hartman
wrote:
> On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
>> Greg,
>>
>> Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
>> >> In which situation on a common Linux system is the current dbus too slow
>> >> today?
>> >>
On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
> Greg,
>
> Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
> >> In which situation on a common Linux system is the current dbus too slow
> >> today?
> >> I've never seen a issue like "Oh my system is slow because dbus is
>
Greg,
Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
>> In which situation on a common Linux system is the current dbus too slow
>> today?
>> I've never seen a issue like "Oh my system is slow because dbus is
>> eating too much CPU cycles".
>
> See the original email which explained all of
On Mon, Apr 20, 2015 at 10:43:19PM +0200, Richard Weinberger wrote:
> David,
>
> On Thu, Apr 16, 2015 at 8:20 PM, David Herrmann wrote:
> > Hi
> >
> > On Wed, Apr 15, 2015 at 8:18 PM, Linus Torvalds
> > wrote:
> >> On Wed, Apr 15, 2015 at 11:11 AM, Greg Kroah-Hartman
> >> wrote:
> >>> On Wed,
David,
On Thu, Apr 16, 2015 at 8:20 PM, David Herrmann wrote:
> Hi
>
> On Wed, Apr 15, 2015 at 8:18 PM, Linus Torvalds
> wrote:
>> On Wed, Apr 15, 2015 at 11:11 AM, Greg Kroah-Hartman
>> wrote:
>>> On Wed, Apr 15, 2015 at 01:33:27PM -0400, Steven Rostedt wrote:
I'll argue that you
> It's used everywhere, on servers,
> embedded systems, desktops, you name it. All languages have bindings
> for it, and it's the underpinning of a modern Linux stack.
Since when? D-bus is some GUI depoendency. On my console-only servers, it's
not needed, and not installed:
# dpkg-query -s
On Mon, Apr 20, 2015 at 5:43 AM, Michal Hocko wrote:
> On Fri 17-04-15 11:54:42, Andy Lutomirski wrote:
>> On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko wrote:
>> > On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
>> >> On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann
>> >> wrote:
>> >> > Hi
>>
On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote:
> Hi,
>
> On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley
> wrote:
> >
> > This is why I think kdbus is a bad idea: it solidifies as a linux kernel
> > API something which runs counter to granular OS virtualization (and
> > something
On Fri 17-04-15 11:54:42, Andy Lutomirski wrote:
> On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko wrote:
> > On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
> >> On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann
> >> wrote:
> >> > Hi
> >> >
> >> > On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski
David,
On Thu, Apr 16, 2015 at 8:20 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Wed, Apr 15, 2015 at 8:18 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Apr 15, 2015 at 11:11 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Apr 15, 2015 at
On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
Greg,
Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
In which situation on a common Linux system is the current dbus too slow
today?
I've never seen a issue like Oh my system is slow because dbus is
eating too
On Mon, Apr 20, 2015 at 2:46 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Mon, Apr 20, 2015 at 11:16:49PM +0200, Richard Weinberger wrote:
Greg,
Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
In which situation on a common Linux system is the current dbus too slow
Greg,
Am 20.04.2015 um 22:56 schrieb Greg Kroah-Hartman:
In which situation on a common Linux system is the current dbus too slow
today?
I've never seen a issue like Oh my system is slow because dbus is
eating too much CPU cycles.
See the original email which explained all of the things
On Mon, Apr 20, 2015 at 10:43:19PM +0200, Richard Weinberger wrote:
David,
On Thu, Apr 16, 2015 at 8:20 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Wed, Apr 15, 2015 at 8:18 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Apr 15, 2015 at 11:11 AM, Greg
It's used everywhere, on servers,
embedded systems, desktops, you name it. All languages have bindings
for it, and it's the underpinning of a modern Linux stack.
Since when? D-bus is some GUI depoendency. On my console-only servers, it's
not needed, and not installed:
# dpkg-query -s
On Fri 17-04-15 11:54:42, Andy Lutomirski wrote:
On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann dh.herrm...@gmail.com
wrote:
Hi
On Thu, Apr 16, 2015 at 4:34 PM,
On Fri, 2015-04-17 at 16:27 -0400, Havoc Pennington wrote:
Hi,
On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
This is why I think kdbus is a bad idea: it solidifies as a linux kernel
API something which runs counter to granular OS
On Mon, Apr 20, 2015 at 5:43 AM, Michal Hocko mho...@suse.cz wrote:
On Fri 17-04-15 11:54:42, Andy Lutomirski wrote:
On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann
Hi
On Thu, Apr 16, 2015 at 10:55 PM, Al Viro wrote:
> On Thu, Apr 16, 2015 at 07:31:22PM +0200, David Herrmann wrote:
>
>> I'm working on patches to add more comments similar to how we did in
>> node.c. For now, please see my explanations below:
>>
>> node->lock is the _innermost_ lock.
>>
Hi
On Thu, Apr 16, 2015 at 10:55 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Thu, Apr 16, 2015 at 07:31:22PM +0200, David Herrmann wrote:
I'm working on patches to add more comments similar to how we did in
node.c. For now, please see my explanations below:
node-lock is the _innermost_
Havoc Pennington wrote:
> Hi,
>
> On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley
> wrote:
>>
>> This is why I think kdbus is a bad idea: it solidifies as a linux kernel
>> API something which runs counter to granular OS virtualization (and
>> something which caused Windows to fall behind
Hi,
On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley
wrote:
>
> This is why I think kdbus is a bad idea: it solidifies as a linux kernel
> API something which runs counter to granular OS virtualization (and
> something which caused Windows to fall behind Linux in the container
> space).
On Thu, 2015-04-16 at 14:13 +0200, David Herrmann wrote:
> Hi
>
> On Wed, Apr 15, 2015 at 8:12 PM, James Bottomley
> wrote:
> > For me the biggest issue is the container problem: it's really hard to
> > containerise kdbus because of the stateful nature of the protocol and
> > the fact that it
On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko wrote:
> On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
>> On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann
>> wrote:
>> > Hi
>> >
>> > On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski
>> > wrote:
>> >> Whose memcg does the pool use?
>> >
>> >
On Wed, 2015-04-15 at 16:48 +0200, Michal Schmidt wrote:
> On 04/15/2015 09:31 AM, Mike Galbraith wrote:
> > it seems [systemd] has now mandated group scheduling.
>
> What makes you think so? Was it the fact that by default you have a
> populated /sys/fs/cgroup/cpu/ hierarchy? This is either
On Fri, Apr 17, 2015 at 9:23 AM, Daniel Mack wrote:
>
> This can only happen with user-originated DBus signal messages. For
> unicast messages such as method calls, the sender will actually see
> -EXFULL, and no part of the message is transmitted, leaving neither side
> in a confused state.
Well
On Thu, Apr 16, 2015 at 06:37:45PM +0200, Robert Schwebel wrote:
> On Wed, Apr 15, 2015 at 11:22:18PM +0100, One Thousand Gnomes wrote:
> > > The reason that 'everyone who works in this area' adopted is not as much
> > > that the design is sound (I'm not arguing whether it is or isn't in this
> >
Hi Havoc,
On 04/16/2015 09:01 PM, Havoc Pennington wrote:
> On Thu, Apr 16, 2015 at 9:13 AM, Tom Gundersen wrote:
>> All types of messages (unicast and broadcast) are directly stored into
>> a pool slice of the receiving connection, and this slice is not reused
>> by the kernel until userspace
On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
> On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann wrote:
> > Hi
> >
> > On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski
> > wrote:
> >> Whose memcg does the pool use?
> >
> > The pool-owner's (i.e., the receiver's).
> >
> >> If it's the
On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski l...@amacapital.net
wrote:
Whose memcg does the pool use?
The pool-owner's (i.e., the receiver's).
Hi Havoc,
On 04/16/2015 09:01 PM, Havoc Pennington wrote:
On Thu, Apr 16, 2015 at 9:13 AM, Tom Gundersen t...@jklm.no wrote:
All types of messages (unicast and broadcast) are directly stored into
a pool slice of the receiving connection, and this slice is not reused
by the kernel until
On Thu, Apr 16, 2015 at 06:37:45PM +0200, Robert Schwebel wrote:
On Wed, Apr 15, 2015 at 11:22:18PM +0100, One Thousand Gnomes wrote:
The reason that 'everyone who works in this area' adopted is not as much
that the design is sound (I'm not arguing whether it is or isn't in this
case) as
On Fri, Apr 17, 2015 at 9:23 AM, Daniel Mack dan...@zonque.org wrote:
This can only happen with user-originated DBus signal messages. For
unicast messages such as method calls, the sender will actually see
-EXFULL, and no part of the message is transmitted, leaving neither side
in a confused
On Wed, 2015-04-15 at 16:48 +0200, Michal Schmidt wrote:
On 04/15/2015 09:31 AM, Mike Galbraith wrote:
it seems [systemd] has now mandated group scheduling.
What makes you think so? Was it the fact that by default you have a
populated /sys/fs/cgroup/cpu/ hierarchy? This is either because
On Fri, Apr 17, 2015 at 2:19 AM, Michal Hocko mho...@suse.cz wrote:
On Thu 16-04-15 10:04:17, Andy Lutomirski wrote:
On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann dh.herrm...@gmail.com
wrote:
Hi
On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski l...@amacapital.net
wrote:
Whose
On Thu, 2015-04-16 at 14:13 +0200, David Herrmann wrote:
Hi
On Wed, Apr 15, 2015 at 8:12 PM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
For me the biggest issue is the container problem: it's really hard to
containerise kdbus because of the stateful nature of the
Hi,
On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
This is why I think kdbus is a bad idea: it solidifies as a linux kernel
API something which runs counter to granular OS virtualization (and
something which caused Windows to fall behind Linux in
Havoc Pennington wrote:
Hi,
On Fri, Apr 17, 2015 at 3:27 PM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
This is why I think kdbus is a bad idea: it solidifies as a linux kernel
API something which runs counter to granular OS virtualization (and
something which caused
On Thu, Apr 16, 2015 at 07:31:22PM +0200, David Herrmann wrote:
> I'm working on patches to add more comments similar to how we did in
> node.c. For now, please see my explanations below:
>
> node->lock is the _innermost_ lock.
> node->active implements revoke
> support for nodes. It follows
On Thu, Apr 16, 2015 at 9:13 AM, Tom Gundersen wrote:
> All types of messages (unicast and broadcast) are directly stored into
> a pool slice of the receiving connection, and this slice is not reused
> by the kernel until userspace is finished with it and frees it. Hence,
> a client which doesn't
Hi
On Wed, Apr 15, 2015 at 8:18 PM, Linus Torvalds
wrote:
> On Wed, Apr 15, 2015 at 11:11 AM, Greg Kroah-Hartman
> wrote:
>> On Wed, Apr 15, 2015 at 01:33:27PM -0400, Steven Rostedt wrote:
>>>
>>> I'll argue that you can't fix the later one. One thing that I've observed
>>> over
>>> the years
Hi,
On Wed, Apr 15, 2015 at 05:07:28PM -0400, Rik van Riel wrote:
[...]
> > This leads me to a potentially interesting question: where's the
> > buffering? If there's a bus with lots of untrusted clients and one of
> > them broadcasts data faster than all receivers can process it, where
> > does
Hi
On Wed, Apr 15, 2015 at 2:36 PM, Al Viro wrote:
> On Wed, Apr 15, 2015 at 11:09:48AM +0200, Greg Kroah-Hartman wrote:
>
>> I've asked for it, but finding people to review code is hard, as you
>> know. It's only 13k lines long, smaller than a serial port driver (my
>> unit of code review), so
> And so does kdbus. By default, strict ordering is enforced when messages
> are received, but optionally, that action may be constrained to messages
> of a minimal priority. This allows for use cases where timing critical
> data is interleaved with control data on the same connection. That's
>
On Wed, Apr 15, 2015 at 11:22:18PM +0100, One Thousand Gnomes wrote:
> > The reason that 'everyone who works in this area' adopted is not as much
> > that the design is sound (I'm not arguing whether it is or isn't in this
> > case) as it is that none of them could come up with anything better.
>
On Thu, Apr 16, 2015 at 8:01 AM, David Herrmann wrote:
> Hi
>
> On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski wrote:
>> Whose memcg does the pool use?
>
> The pool-owner's (i.e., the receiver's).
>
>> If it's the receiver's, and if the
>> receiver can configure a memcg, then it seems that
On Wed, Apr 15, 2015 at 6:22 PM, One Thousand Gnomes
wrote:
> Actually most message passing code uses things like JMS and the various
> MQ libraries. Most IoT uses things other than dbus, small deep embedded
> never uses dbus.
fwiw, to me it's a mistake to think of dbus as "the same space" as
Hi
On Thu, Apr 16, 2015 at 4:34 PM, Andy Lutomirski wrote:
> Whose memcg does the pool use?
The pool-owner's (i.e., the receiver's).
> If it's the receiver's, and if the
> receiver can configure a memcg, then it seems that even a single
> receiver could probably cause the sender to block for
301 - 400 of 698 matches
Mail list logo
