On Sun, Aug 9, 2015 at 3:11 PM, Daniel Mack wrote:
>
> The kdbus implementation is actually comparable to two tasks X and Y
> which both have their own buffer file open and mmap()ed, and they both
> pass their FD to the other side. If X now writes to Y's file, and that
> is causing a page fault,
On Sun, Aug 9, 2015 at 3:11 PM, Daniel Mack dan...@zonque.org wrote:
The kdbus implementation is actually comparable to two tasks X and Y
which both have their own buffer file open and mmap()ed, and they both
pass their FD to the other side. If X now writes to Y's file, and that
is causing a
On Sun, 9 Aug 2015, Greg Kroah-Hartman wrote:
The issue is with userspace clients opting in to receive all
NameOwnerChanged messages on the bus, which is not a good idea as they
constantly get woken up and process them, which is why the CPU was
pegged. This issue should now be fixed in Rawhide
On Sun, Aug 9, 2015 at 3:11 PM, Daniel Mack wrote:
>
> Internally, the connection pool is simply a shmem backed file. From the
> context of the HELLO ioctl, we are calling into shmem_file_setup(), so
> the file is eventually owned by the task which created the bus task
> connecting to the bus.
On 08/09/2015 09:00 PM, Greg Kroah-Hartman wrote:
> In chatting with Daniel on IRC, he is writing up a summary of how the
> kdbus memory pools work in more detail, and he said he would sent that
> out in a day or so, so that everyone can review.
Yes, let me quickly describe again how the kdbus
On Fri, Aug 07, 2015 at 06:26:31PM +0300, Linus Torvalds wrote:
> User space memory allocation is not AT ALL the same thing as kdbus.
> Kernel allocations are very very different from user allocations. We
> have reasonable, fairly tested, and generic models for handling user
> space memory
On Fri, Aug 07, 2015 at 06:26:31PM +0300, Linus Torvalds wrote:
User space memory allocation is not AT ALL the same thing as kdbus.
Kernel allocations are very very different from user allocations. We
have reasonable, fairly tested, and generic models for handling user
space memory allocation
On 08/09/2015 09:00 PM, Greg Kroah-Hartman wrote:
In chatting with Daniel on IRC, he is writing up a summary of how the
kdbus memory pools work in more detail, and he said he would sent that
out in a day or so, so that everyone can review.
Yes, let me quickly describe again how the kdbus pool
On Sun, Aug 9, 2015 at 3:11 PM, Daniel Mack dan...@zonque.org wrote:
Internally, the connection pool is simply a shmem backed file. From the
context of the HELLO ioctl, we are calling into shmem_file_setup(), so
the file is eventually owned by the task which created the bus task
connecting to
On Sun, 9 Aug 2015, Greg Kroah-Hartman wrote:
The issue is with userspace clients opting in to receive all
NameOwnerChanged messages on the bus, which is not a good idea as they
constantly get woken up and process them, which is why the CPU was
pegged. This issue should now be fixed in Rawhide
2015-08-07 2:43 GMT+08:00 Andy Lutomirski :
> On Thu, Aug 6, 2015 at 11:14 AM, Daniel Mack wrote:
>> On 08/06/2015 05:21 PM, Andy Lutomirski wrote:
>>> Maybe gdbus really does use kdbus already, but on
>>> very brief inspection it looked like it didn't at least on my test VM.
>>
>> No, it's not
On Fri, Aug 7, 2015 at 7:40 AM, Daniel Mack wrote:
> On 08/06/2015 08:43 PM, Andy Lutomirski wrote:
>> Nonetheless, it looks like the slice logic (aside: it looks *way* more
>> complicated than necessary -- what's wrong with circular buffers)
>> will, under most (but not all!) workloads,
On 08/06/2015 08:43 PM, Andy Lutomirski wrote:
> Nonetheless, it looks like the slice logic (aside: it looks *way* more
> complicated than necessary -- what's wrong with circular buffers)
> will, under most (but not all!) workloads, concentrate access to a
> smallish fraction of the pool. This is
2015-08-07 2:43 GMT+08:00 Andy Lutomirski l...@amacapital.net:
On Thu, Aug 6, 2015 at 11:14 AM, Daniel Mack dan...@zonque.org wrote:
On 08/06/2015 05:21 PM, Andy Lutomirski wrote:
Maybe gdbus really does use kdbus already, but on
very brief inspection it looked like it didn't at least on my
On Fri, Aug 7, 2015 at 7:40 AM, Daniel Mack dan...@zonque.org wrote:
On 08/06/2015 08:43 PM, Andy Lutomirski wrote:
Nonetheless, it looks like the slice logic (aside: it looks *way* more
complicated than necessary -- what's wrong with circular buffers)
will, under most (but not all!)
On 08/06/2015 08:43 PM, Andy Lutomirski wrote:
Nonetheless, it looks like the slice logic (aside: it looks *way* more
complicated than necessary -- what's wrong with circular buffers)
will, under most (but not all!) workloads, concentrate access to a
smallish fraction of the pool. This is IMO
On Thu, Aug 6, 2015 at 11:14 AM, Daniel Mack wrote:
> On 08/06/2015 05:21 PM, Andy Lutomirski wrote:
>> Maybe gdbus really does use kdbus already, but on
>> very brief inspection it looked like it didn't at least on my test VM.
>
> No, it's not in any released version yet. The patches for that
On 08/06/2015 05:21 PM, Andy Lutomirski wrote:
> Maybe gdbus really does use kdbus already, but on
> very brief inspection it looked like it didn't at least on my test VM.
No, it's not in any released version yet. The patches for that are being
worked on though and look promising.
> If the
On 08/06/2015 05:27 PM, Andy Lutomirski wrote:
>> In DBus (both kdbus and DBus1), such matches are installed on the
>> > NameOwnerChanged signal, and they can be either specific to a single ID,
>> > or broad, which will make them match on any ID. There's actually no
>> > reason for applications to
On Thu, Aug 6, 2015 at 12:06 AM, Daniel Mack wrote:
> Hi Andy,
>
> On 08/05/2015 02:18 AM, Andy Lutomirski wrote:
>> I added the missing sd_bus_unref call.
>>
>> With userspace dbus, my program takes 95% CPU and dbus-daemon takes
>> 88% CPU or so.
>>
>> With kdbus, I see abuse-bus (my test),
On Aug 6, 2015 1:04 AM, "David Herrmann" wrote:
> > Given that all existing prototype userspace that I'm aware of
> > (systemd and its consumers) apparently opts in, I don't really care
> > that the feature is opt-in.
>
> This is just plain wrong. Out of the dozens of dbus applications,
Am Donnerstag, 6. August 2015, 10:04:57 schrieb David Herrmann:
> > Given that all existing prototype userspace that I'm aware of
> >
> > (systemd and its consumers) apparently opts in, I don't really care
> > that the feature is opt-in.
>
> This is just plain wrong. Out of the dozens of
Hi
On Wed, Aug 5, 2015 at 10:11 PM, Andy Lutomirski wrote:
> On Wed, Aug 5, 2015 at 12:10 AM, David Herrmann wrote:
>> Hi
>>
>> On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski wrote:
>>> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann
>>> wrote:
This is a bug in the proxy (which is
Hi Andy,
On 08/05/2015 02:18 AM, Andy Lutomirski wrote:
> I added the missing sd_bus_unref call.
>
> With userspace dbus, my program takes 95% CPU and dbus-daemon takes
> 88% CPU or so.
>
> With kdbus, I see abuse-bus (my test), systemd-journald,
> systemd-bus-proxy, auditd, gnome-shell,
Hi Andy,
On 08/05/2015 02:18 AM, Andy Lutomirski wrote:
I added the missing sd_bus_unref call.
With userspace dbus, my program takes 95% CPU and dbus-daemon takes
88% CPU or so.
With kdbus, I see abuse-bus (my test), systemd-journald,
systemd-bus-proxy, auditd, gnome-shell,
On 08/06/2015 05:21 PM, Andy Lutomirski wrote:
Maybe gdbus really does use kdbus already, but on
very brief inspection it looked like it didn't at least on my test VM.
No, it's not in any released version yet. The patches for that are being
worked on though and look promising.
If the client
On Thu, Aug 6, 2015 at 11:14 AM, Daniel Mack dan...@zonque.org wrote:
On 08/06/2015 05:21 PM, Andy Lutomirski wrote:
Maybe gdbus really does use kdbus already, but on
very brief inspection it looked like it didn't at least on my test VM.
No, it's not in any released version yet. The patches
On 08/06/2015 05:27 PM, Andy Lutomirski wrote:
In DBus (both kdbus and DBus1), such matches are installed on the
NameOwnerChanged signal, and they can be either specific to a single ID,
or broad, which will make them match on any ID. There's actually no
reason for applications to install
Hi
On Wed, Aug 5, 2015 at 10:11 PM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Aug 5, 2015 at 12:10 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann
On Aug 6, 2015 1:04 AM, David Herrmann dh.herrm...@gmail.com wrote:
Given that all existing prototype userspace that I'm aware of
(systemd and its consumers) apparently opts in, I don't really care
that the feature is opt-in.
This is just plain wrong. Out of the dozens of dbus
Am Donnerstag, 6. August 2015, 10:04:57 schrieb David Herrmann:
Given that all existing prototype userspace that I'm aware of
(systemd and its consumers) apparently opts in, I don't really care
that the feature is opt-in.
This is just plain wrong. Out of the dozens of dbus
On Thu, Aug 6, 2015 at 12:06 AM, Daniel Mack dan...@zonque.org wrote:
Hi Andy,
On 08/05/2015 02:18 AM, Andy Lutomirski wrote:
I added the missing sd_bus_unref call.
With userspace dbus, my program takes 95% CPU and dbus-daemon takes
88% CPU or so.
With kdbus, I see abuse-bus (my test),
On Wed, Aug 5, 2015 at 12:10 AM, David Herrmann wrote:
> Hi
>
> On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski wrote:
>> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann wrote:
>>> This is a bug in the proxy (which is already fixed).
>>
>> Should I expect to see it in Rawhide soon?
>
> Use this
Hi
On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski wrote:
> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann wrote:
>> This is a bug in the proxy (which is already fixed).
>
> Should I expect to see it in Rawhide soon?
Use this workaround until it does:
$
Hi
On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann dh.herrm...@gmail.com wrote:
This is a bug in the proxy (which is already fixed).
Should I expect to see it in Rawhide soon?
Use this workaround until it does:
$
On Wed, Aug 5, 2015 at 12:10 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Tue, Aug 4, 2015 at 4:47 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann dh.herrm...@gmail.com wrote:
This is a bug in the proxy (which is already fixed).
Should
On Tue, Aug 4, 2015 at 7:47 AM, Andy Lutomirski wrote:
> On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann wrote:
>> Hi
>>
>> On Tue, Aug 4, 2015 at 3:46 PM, Linus Torvalds
>> wrote:
>>> On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann
>>> wrote:
You lack a call to sd_bus_unref() here.
On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann wrote:
> Hi
>
> On Tue, Aug 4, 2015 at 3:46 PM, Linus Torvalds
> wrote:
>> On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann wrote:
>>>
>>> You lack a call to sd_bus_unref() here.
>>
>> I assume it was intentional. Why would Andy talk about "scaling"
Hi
On Tue, Aug 4, 2015 at 3:46 PM, Linus Torvalds
wrote:
> On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann wrote:
>>
>> You lack a call to sd_bus_unref() here.
>
> I assume it was intentional. Why would Andy talk about "scaling" otherwise?
>
> And the worry was why the kdbus version killed the
On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann wrote:
>
> You lack a call to sd_bus_unref() here.
I assume it was intentional. Why would Andy talk about "scaling" otherwise?
And the worry was why the kdbus version killed the machine, but the
userspace version did not. That's a rather big
Hi
On Tue, Aug 4, 2015 at 1:02 AM, Andy Lutomirski wrote:
>I got Fedora
> Rawhide working under kdbus (thanks, everyone!), and I ran this little
> program:
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> while (1) {
>
Hi
On Tue, Aug 4, 2015 at 1:02 AM, Andy Lutomirski l...@kernel.org wrote:
I got Fedora
Rawhide working under kdbus (thanks, everyone!), and I ran this little
program:
#include systemd/sd-bus.h
#include err.h
int main(int argc, char *argv[])
Hi
On Tue, Aug 4, 2015 at 3:46 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann dh.herrm...@gmail.com wrote:
You lack a call to sd_bus_unref() here.
I assume it was intentional. Why would Andy talk about scaling otherwise?
And the worry
On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann dh.herrm...@gmail.com wrote:
You lack a call to sd_bus_unref() here.
I assume it was intentional. Why would Andy talk about scaling otherwise?
And the worry was why the kdbus version killed the machine, but the
userspace version did not. That's a
On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Tue, Aug 4, 2015 at 3:46 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann dh.herrm...@gmail.com wrote:
You lack a call to sd_bus_unref() here.
I assume
On Tue, Aug 4, 2015 at 7:47 AM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Aug 4, 2015 at 7:09 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Tue, Aug 4, 2015 at 3:46 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Aug 4, 2015 at 1:58 AM, David Herrmann
On Mon, Jun 22, 2015 at 11:06 PM, Andy Lutomirski wrote:
> 2. Kdbus introduces a novel buffering model. Receivers allocate a big
> chunk of what's essentially tmpfs space. Assuming that space is
> available (in a virtual memory sense), senders synchronously write to
> the receivers' tmpfs
On Mon, Jun 22, 2015 at 11:06 PM, Andy Lutomirski l...@amacapital.net wrote:
2. Kdbus introduces a novel buffering model. Receivers allocate a big
chunk of what's essentially tmpfs space. Assuming that space is
available (in a virtual memory sense), senders synchronously write to
the
On Thu 2015-07-09 10:39:58, Geert Uytterhoeven wrote:
> On Wed, Jul 8, 2015 at 3:54 PM, Pavel Machek wrote:
> > Apparently, new tools are needed in the community, as normal review
> > comments did not stop drivers/android/binder.c merge.
> >
> > For example binder_transaction does not exactly
On Thu, Jul 9, 2015 at 12:29 PM, Joe Perches wrote:
> On Thu, 2015-07-09 at 10:39 +0200, Geert Uytterhoeven wrote:
>> On Wed, Jul 8, 2015 at 3:54 PM, Pavel Machek wrote:
>> > Apparently, new tools are needed in the community, as normal review
>> > comments did not stop drivers/android/binder.c
On Thu, 2015-07-09 at 10:39 +0200, Geert Uytterhoeven wrote:
> On Wed, Jul 8, 2015 at 3:54 PM, Pavel Machek wrote:
> > Apparently, new tools are needed in the community, as normal review
> > comments did not stop drivers/android/binder.c merge.
> >
> > For example binder_transaction does not
On Wed, Jul 8, 2015 at 3:54 PM, Pavel Machek wrote:
> Apparently, new tools are needed in the community, as normal review
> comments did not stop drivers/android/binder.c merge.
>
> For example binder_transaction does not exactly look like a kernel
> code, "TODO: fput" does not really invoke
On Wed, Jul 8, 2015 at 3:54 PM, Pavel Machek pa...@ucw.cz wrote:
Apparently, new tools are needed in the community, as normal review
comments did not stop drivers/android/binder.c merge.
For example binder_transaction does not exactly look like a kernel
code, TODO: fput does not really invoke
On Thu, Jul 9, 2015 at 12:29 PM, Joe Perches j...@perches.com wrote:
On Thu, 2015-07-09 at 10:39 +0200, Geert Uytterhoeven wrote:
On Wed, Jul 8, 2015 at 3:54 PM, Pavel Machek pa...@ucw.cz wrote:
Apparently, new tools are needed in the community, as normal review
comments did not stop
On Thu 2015-07-09 10:39:58, Geert Uytterhoeven wrote:
On Wed, Jul 8, 2015 at 3:54 PM, Pavel Machek pa...@ucw.cz wrote:
Apparently, new tools are needed in the community, as normal review
comments did not stop drivers/android/binder.c merge.
For example binder_transaction does not exactly
On Thu, 2015-07-09 at 10:39 +0200, Geert Uytterhoeven wrote:
On Wed, Jul 8, 2015 at 3:54 PM, Pavel Machek pa...@ucw.cz wrote:
Apparently, new tools are needed in the community, as normal review
comments did not stop drivers/android/binder.c merge.
For example binder_transaction does not
On Mon 2015-06-22 23:41:40, Greg KH wrote:
> On Mon, Jun 22, 2015 at 11:06:09PM -0700, Andy Lutomirski wrote:
> > Hi Linus,
> >
> > Can you opine as to whether you think that kdbus should be merged?
>
> Ah, a preemptive pull request denial, how nice.
> I don't think I've ever seen such a thing
On Mon 2015-06-22 23:41:40, Greg KH wrote:
On Mon, Jun 22, 2015 at 11:06:09PM -0700, Andy Lutomirski wrote:
Hi Linus,
Can you opine as to whether you think that kdbus should be merged?
Ah, a preemptive pull request denial, how nice.
I don't think I've ever seen such a thing before,
On Wed, Jul 01, 2015 at 06:51:41PM +0200, David Herrmann wrote:
> Hi
>
Thanks for the answers; in response I've got some further questions. Again,
apologies for length -- I apparently don't know how to discuss IPC tersely.
> On Wed, Jul 1, 2015 at 2:03 AM, Kalle A. Sandstrom wrote:
> > For the
On Wed, Jul 01, 2015 at 06:51:41PM +0200, David Herrmann wrote:
Hi
Thanks for the answers; in response I've got some further questions. Again,
apologies for length -- I apparently don't know how to discuss IPC tersely.
On Wed, Jul 1, 2015 at 2:03 AM, Kalle A. Sandstrom ksand...@iki.fi wrote:
Hi
On Wed, Jul 1, 2015 at 2:03 AM, Kalle A. Sandstrom wrote:
> For the first, compare unix domain sockets (i.e. point-to-point mode, access
> control through filesystem [or fork() parentage], read/write/select) to the
> kdbus message-sending ioctl. In the main data-exchanging portion, the former
Hi
On Wed, Jul 1, 2015 at 2:03 AM, Kalle A. Sandstrom ksand...@iki.fi wrote:
For the first, compare unix domain sockets (i.e. point-to-point mode, access
control through filesystem [or fork() parentage], read/write/select) to the
kdbus message-sending ioctl. In the main data-exchanging
[delurk; apparently kdbus is not receiving the architectural review it should.
i've got quite a bit of knowledge on message-passing mechanisms in general, and
kernel IPC in particular, so i'll weigh in uninvited. apologies for length.
as my "proper" review on this topic is still under
[delurk; apparently kdbus is not receiving the architectural review it should.
i've got quite a bit of knowledge on message-passing mechanisms in general, and
kernel IPC in particular, so i'll weigh in uninvited. apologies for length.
as my proper review on this topic is still under
On Thu, Jun 25, 2015 at 09:57:45AM +0200, Geert Uytterhoeven wrote:
> >
> > in-kernel webserver
>
> Which was cool, and small, and _faster_ than anything else...
> Until it was integrated, and people working on (userspace) webservers
> started considering its performance as a target, and soon it
Am Donnerstag, 25. Juni 2015, 09:34:56 schrieb Theodore Ts'o:
> On Thu, Jun 25, 2015 at 08:05:58AM +0200, Martin Steigerwald wrote:
> > Or, do you think, that there is a different option to handle this then
> > the both I outlined above?
>
> Hmm... distros could have their engineers **fix** the
On Thu, Jun 25, 2015 at 08:05:58AM +0200, Martin Steigerwald wrote:
>
> Or, do you think, that there is a different option to handle this then the
> both I outlined above?
Hmm... distros could have their engineers **fix** the busted userspace
code, instead of fixing the problem by jamming a
On Wed, Jun 24, 2015 at 9:12 PM, David Lang wrote:
> On Wed, 24 Jun 2015, Martin Steigerwald wrote:
>> Am Mittwoch, 24. Juni 2015, 10:39:52 schrieb David Lang:
>>> On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down
the line,
* Ingo Molnar wrote:
>
> * David Lang wrote:
>
> > On Wed, 24 Jun 2015, Ingo Molnar wrote:
> >
> > > And the thing is, in hindsight, after such huge flamewars, years down the
> > > line, almost never do I see the following question asked: 'what were we
> > > thinking merging that crap??'.
* David Lang wrote:
> On Wed, 24 Jun 2015, Ingo Molnar wrote:
>
> > And the thing is, in hindsight, after such huge flamewars, years down the
> > line, almost never do I see the following question asked: 'what were we
> > thinking merging that crap??'. If any question arises it's usually
On Wed, 24 Jun 2015, Greg KH wrote:
On Wed, Jun 24, 2015 at 10:39:52AM -0700, David Lang wrote:
On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down the line,
almost never do I see the following question asked: 'what were we thinking
On Wed, Jun 24, 2015 at 10:39:52AM -0700, David Lang wrote:
> On Wed, 24 Jun 2015, Ingo Molnar wrote:
>
> >And the thing is, in hindsight, after such huge flamewars, years down the
> >line,
> >almost never do I see the following question asked: 'what were we thinking
> >merging
> >that crap??'.
gt; their own QA, and handle fallout from whatever problems they encounter
> > etc. That part might be good. But I don't think we really end up
> > having the option to make up some incompatible kdbus ABI
> > after-the-fact.
>
> Linus, so is that a recommendation to the di
I
> after-the-fact.
Linus, so is that a recommendation to the distros to be careful to put kdbus
into the distro kernel right now and probably better defer it or are you
thinking that the ABI of kdbus already is suitable for merging and you see
no issues to merge a kdbus with the ABI it currently has,
On Wed, 24 Jun 2015, Greg KH wrote:
On Wed, Jun 24, 2015 at 10:39:52AM -0700, David Lang wrote:
On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down the line,
almost never do I see the following question asked: 'what were we thinking
* David Lang da...@lang.hm wrote:
On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down the
line, almost never do I see the following question asked: 'what were we
thinking merging that crap??'. If any question arises it's
* Ingo Molnar mi...@kernel.org wrote:
* David Lang da...@lang.hm wrote:
On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down the
line, almost never do I see the following question asked: 'what were we
thinking merging
On Wed, Jun 24, 2015 at 9:12 PM, David Lang da...@lang.hm wrote:
On Wed, 24 Jun 2015, Martin Steigerwald wrote:
Am Mittwoch, 24. Juni 2015, 10:39:52 schrieb David Lang:
On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down
the line,
On Thu, Jun 25, 2015 at 08:05:58AM +0200, Martin Steigerwald wrote:
Or, do you think, that there is a different option to handle this then the
both I outlined above?
Hmm... distros could have their engineers **fix** the busted userspace
code, instead of fixing the problem by jamming a
On Thu, Jun 25, 2015 at 09:57:45AM +0200, Geert Uytterhoeven wrote:
in-kernel webserver
Which was cool, and small, and _faster_ than anything else...
Until it was integrated, and people working on (userspace) webservers
started considering its performance as a target, and soon it was
Am Donnerstag, 25. Juni 2015, 09:34:56 schrieb Theodore Ts'o:
On Thu, Jun 25, 2015 at 08:05:58AM +0200, Martin Steigerwald wrote:
Or, do you think, that there is a different option to handle this then
the both I outlined above?
Hmm... distros could have their engineers **fix** the busted
right now and probably better defer it or are you
thinking that the ABI of kdbus already is suitable for merging and you see
no issues to merge a kdbus with the ABI it currently has, but probably
otherwise improved?
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C
On Wed, Jun 24, 2015 at 10:39:52AM -0700, David Lang wrote:
On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down the
line,
almost never do I see the following question asked: 'what were we thinking
merging
that crap??'. If any
.
Linus, so is that a recommendation to the distros to be careful to put
kdbus into the distro kernel right now and probably better defer it or
are you thinking that the ABI of kdbus already is suitable for merging
and you see no issues to merge a kdbus with the ABI it currently has, but
probably
On Wed, Jun 24, 2015 at 7:14 PM, Steven Rostedt wrote:
>
> I don't think it will complicate things even if the API changes. The distros
> will have to deal with that fall out. Mainline only cares about its own
> regressions. But any API changes would only be done for good reasons, and give
> the
On Tue, Jun 23, 2015 at 08:07:41AM -0700, Andy Lutomirski wrote:
>
> FWIW, once there are real distros with kdbus userspace enabled,
> reviewing kdbus gets more complicated -- we'll be in the position
> where merging kdbus in a different form from that which was proposed
> will break existing
On Wed, Jun 24, 2015 at 9:43 PM, Andy Lutomirski wrote:
> On Wed, Jun 24, 2015 at 10:11 AM, Alexander Larsson
> wrote:
>> My name is on the dbus specification, and I am (and was
>> then) well aware of systems with object references. In fact, both
>> previous ipc systems (Corba ORBs) that Gnome
On Wed, Jun 24, 2015 at 10:11 AM, Alexander Larsson
wrote:
> On Wed, Jun 24, 2015 at 5:38 PM, Andy Lutomirski wrote:
>> Was this intentionally off-list?
>
> Nah, that was a mistake, adding back the list.
>
>> On Wed, Jun 24, 2015 at 8:10 AM, Alexander Larsson
>
>>> The way i did it in the
On Wed, 24 Jun 2015, Martin Steigerwald wrote:
Am Mittwoch, 24. Juni 2015, 10:39:52 schrieb David Lang:
On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down
the line, almost never do I see the following question asked: 'what
were we
Am Mittwoch, 24. Juni 2015, 10:39:52 schrieb David Lang:
> On Wed, 24 Jun 2015, Ingo Molnar wrote:
> > And the thing is, in hindsight, after such huge flamewars, years down
> > the line, almost never do I see the following question asked: 'what
> > were we thinking merging that crap??'. If any
David Lang writes:
> On Wed, 24 Jun 2015, Ingo Molnar wrote:
>
>> And the thing is, in hindsight, after such huge flamewars, years down the
>> line,
>> almost never do I see the following question asked: 'what were we thinking
>> merging
>> that crap??'. If any question arises it's usually
On Wed, 24 Jun 2015, Ingo Molnar wrote:
And the thing is, in hindsight, after such huge flamewars, years down the line,
almost never do I see the following question asked: 'what were we thinking
merging
that crap??'. If any question arises it's usually along the lines of: 'what was
the big
On Wed, Jun 24, 2015 at 5:38 PM, Andy Lutomirski wrote:
> Was this intentionally off-list?
Nah, that was a mistake, adding back the list.
> On Wed, Jun 24, 2015 at 8:10 AM, Alexander Larsson
>> The way i did it in the userspace proxy is to allow peer exited
>> messages from services that
On Wed, Jun 24, 2015 at 2:55 AM, Alexander Larsson
wrote:
>
> I don't really understand this objection. I'm working on an
> application sandboxing model for desktop applications (xdg-app), and
> the kdbus model matches my needs well. In fact, I'm currently using a
> userspace filtering proxy that
* Martin Steigerwald wrote:
> Am Mittwoch, 24. Juni 2015, 10:05:02 schrieb Ingo Molnar:
> > Not because I like it so much, but because I think the merge process
> > should be stripped of politics and emotion as much as possible: if an
> > initial submission is good and addresses all technical
* Martin Steigerwald wrote:
> Am Mittwoch, 24. Juni 2015, 10:05:02 schrieb Ingo Molnar:
>
> > - Once one (or two) major distros go with kdbus, it becomes a de-facto
> > ABI.
> > If the ABI is bad then that distro will hurt from it regardless of whether
> > we
> > merge it upstream or not -
Am Mittwoch, 24. Juni 2015, 10:05:02 schrieb Ingo Molnar:
> Not because I like it so much, but because I think the merge process
> should be stripped of politics and emotion as much as possible: if an
> initial submission is good and addresses all technical review properly,
> and if the cost to
Am Mittwoch, 24. Juni 2015, 10:05:02 schrieb Ingo Molnar:
> - Once one (or two) major distros go with kdbus, it becomes a de-facto
> ABI. If the ABI is bad then that distro will hurt from it regardless of
> whether we merge it upstream or not - so technical pressure is there to
> improve it. But
Ingo Molnar writes:
> Not because I like it so much, but because I think the merge process should
> be
> stripped of politics and emotion as much as possible: if an initial
> submission is
> good and addresses all technical review properly, and if the cost to the core
> kernel is low, then
On Tue, Jun 23, 2015 at 8:06 AM, Andy Lutomirski wrote:
> 3. The sandbox model is, in my opinion, an experiment that isn't going
> to succeed. It's a poor model: a "restricted endpoint" (i.e. a
> sandboxed kdbus client) sees a view of the world defined by a limited
> policy language implemented
1 - 100 of 138 matches
Mail list logo
