On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 1:15 PM, David Lang da...@lang.hm wrote:
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr
On Wed, Apr 29, 2015 at 1:15 PM, David Lang da...@lang.hm wrote:
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, Harald Hoyer
Hi
On Wed, Apr 29, 2015 at 10:43 PM, David Lang da...@lang.hm wrote:
If the justification for why this needs to be in the kernel is that you
can't reliably prevent apps from exiting if there are pending messages, [...]
It's not.
the answer of preventing apps from exiting if there are pending
On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
If your customers wnat this feature, you're more than welcome to fork
the kernel and support it yourself. Oh wait... Redhat does that
already. So what's the problem? Just put it into RHEL (which I use
I admit, along with
On Wed, 29 Apr 2015, Theodore Ts'o wrote:
On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
If your customers wnat this feature, you're more than welcome to fork
the kernel and support it yourself. Oh wait... Redhat does that
already. So what's the problem? Just put it into
On Thu, 30 Apr 2015, Dave Airlie wrote:
On 30 April 2015 at 10:05, David Lang da...@lang.hm wrote:
On Wed, 29 Apr 2015, Theodore Ts'o wrote:
On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
If your customers wnat this feature, you're more than welcome to fork
the kernel and
On 30 April 2015 at 10:05, David Lang da...@lang.hm wrote:
On Wed, 29 Apr 2015, Theodore Ts'o wrote:
On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
If your customers wnat this feature, you're more than welcome to fork
the kernel and support it yourself. Oh wait... Redhat does
Austin == Austin S Hemmelgarn ahferro...@gmail.com writes:
Austin On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, Harald Hoyer har...@redhat.com wrote:
* Being in the kernel closes a lot of races which can't be fixed with
the current userspace solutions. For example,
On 04/29/2015 08:47 AM, Harald Hoyer wrote:
On 29.04.2015 01:12, John Stoffel wrote:
LDAP is pretty damn generic, in that you can put pretty large objects into
it, and pretty large OUs, etc. So why would it be a candidate for going
into the kernel? And why is kdbus so important in the kernel
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define beginning. To me an initramfs is a *very* minimal
tool to prepare the rootfs and nothing more (no udev, no systemd, no
mini distro).
If the initramfs fails to do its job it can print to the console like
the kernel does
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define beginning. To me an initramfs is a *very*
minimal
tool to prepare the rootfs and nothing more (no udev, no systemd, no
mini
On 29.04.2015 16:04, Richard Weinberger wrote:
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define beginning. To me an initramfs is a
On Wed, Apr 29, 2015 at 2:47 PM, Harald Hoyer har...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29.04.2015 01:12, John Stoffel wrote:
LDAP is pretty damn generic, in that you can put pretty large objects into
it, and pretty large OUs, etc. So why would it be a
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define beginning. To me an initramfs is a *very* minimal
tool to prepare the rootfs and nothing more (no udev, no systemd, no
mini distro).
If the initramfs fails to do its job it
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you define beginning. To me an initramfs is a *very*
minimal
tool to prepare the rootfs and
Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
We don't handcraft the initramfs script for every our customers, therefore
we
have to generically support hotplug, persistent device names, persistent
interface names, network connectivity in the initramfs, user input handling
for
passwords,
On 2015-04-29 10:11, Harald Hoyer wrote:
On 29.04.2015 16:04, Richard Weinberger wrote:
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015 15:33, Richard Weinberger wrote:
It depends how you
On 29.04.2015 16:18, Richard Weinberger wrote:
Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
We don't handcraft the initramfs script for every our customers, therefore
we
have to generically support hotplug, persistent device names, persistent
interface names, network connectivity in the
Am 29.04.2015 um 16:46 schrieb Austin S Hemmelgarn:
On 2015-04-29 10:11, Harald Hoyer wrote:
On 29.04.2015 16:04, Richard Weinberger wrote:
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015
I've had Enterprise systems where I could hit power on two boxes, and
finish
the OS install on one before the other has even finished POST and look
for
the boot media. I did this 5 years ago, before the let's speed up boot
push started.
Admittedly, this wasn't a stock distro boot/install,
David == David Herrmann dh.herrm...@gmail.com writes:
David Hi
David On Wed, Apr 29, 2015 at 10:43 PM, David Lang da...@lang.hm wrote:
If the justification for why this needs to be in the kernel is that you
can't reliably prevent apps from exiting if there are pending messages, [...]
David
On 2015-04-29 11:03, Theodore Ts'o wrote:
On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote:
Sure, I can write one binary to rule them all, pull out all the code from all
tools I need, but for me an IPC mechanism sounds a lot better. And it should be
_one_ common IPC mechanism and
On 29.04.2015 17:17, Austin S Hemmelgarn wrote:
On 2015-04-29 11:07, Harald Hoyer wrote:
Most of the stuff does not work without udev and something like systemd.
That's funny, apparently the initramfs images I've been using for multiple
months now on server systems at work which don't have
Am Mittwoch, 29. April 2015, 14:47:53 schrieb Harald Hoyer:
We really don't want the IPC mechanism to be in a flux state. All tools
have to fallback to a non-standard mechanism in that case.
If I have to pull in a dbus daemon in the initramfs, we still have the
chicken and egg problem for
On 2015-04-29 11:22, Harald Hoyer wrote:
On 29.04.2015 17:17, Austin S Hemmelgarn wrote:
On 2015-04-29 11:07, Harald Hoyer wrote:
Most of the stuff does not work without udev and something like systemd.
That's funny, apparently the initramfs images I've been using for multiple
months now on
On Wed, Apr 29, 2015 at 04:53:53PM +0200, Harald Hoyer wrote:
Sure, I can write one binary to rule them all, pull out all the code from all
tools I need, but for me an IPC mechanism sounds a lot better. And it should
be
_one_ common IPC mechanism and not a plethora of them. It should feel
On 2015-04-29 11:07, Harald Hoyer wrote:
Most of the stuff does not work without udev and something like systemd.
That's funny, apparently the initramfs images I've been using for
multiple months now on server systems at work which don't have systemd,
udev, or dbus, and do LVM/RAID assembly,
Am 29.04.2015 um 16:53 schrieb Harald Hoyer:
On 29.04.2015 16:18, Richard Weinberger wrote:
Am 29.04.2015 um 16:11 schrieb Harald Hoyer:
We don't handcraft the initramfs script for every our customers,
therefore we
have to generically support hotplug, persistent device names, persistent
On 29.04.2015 16:46, Austin S Hemmelgarn wrote:
On 2015-04-29 10:11, Harald Hoyer wrote:
On 29.04.2015 16:04, Richard Weinberger wrote:
Am 29.04.2015 um 16:01 schrieb Harald Hoyer:
On 29.04.2015 15:46, Richard Weinberger wrote:
Am 29.04.2015 um 15:38 schrieb Harald Hoyer:
On 29.04.2015
On 29/04/15 14:35, Stephen Smalley wrote:
As it currently stands, there
are no LSM hook calls in the kdbus tree beyond metadata collection of
security labels.
SELinux and AppArmor are the two particularly interesting LSMs here:
those are the ones that have support for user-space mediation in
On Tue, Apr 28, 2015 at 7:12 PM, John Stoffel wrote:
> Havoc> Yeah. I don't know how you answer that, because the answer is
> Havoc> probably "it would be good enough for some things and not for
> Havoc> other things." It depends on whether an app is sending enough
> Havoc> data to be too slow,
> "Havoc" == Havoc Pennington writes:
Havoc> On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote:
>> So the question is if one of the justifications for moving the daemon
>> into kernel space is that it's performance is crap, then I think it is
>> useful to determine whether a fully
On Tue, Apr 28, 2015 at 12:19 PM, Havoc Pennington wrote:
>
> From what I can tell, the core performance claim for kdbus is that for
> a userspace daemon to be a routing intermediary, it has to receive and
> re-send messages. If the baseline performance of IPC is the cost to
> send once and
On Tue, Apr 28, 2015 at 1:34 PM, David Lang wrote:
> On Tue, 28 Apr 2015, Havoc Pennington wrote:
>
>> On Tue, Apr 28, 2015 at 1:19 PM, David Lang wrote:
>>>
>>> If the examples that are being used to show the performance advantage of
>>> kdbus vs normal dbus are doing the wrong thing, then we
On Tue, 28 Apr 2015, Havoc Pennington wrote:
On Tue, Apr 28, 2015 at 1:19 PM, David Lang wrote:
If the examples that are being used to show the performance advantage of
kdbus vs normal dbus are doing the wrong thing, then we need to get some
other examples available to people who don't live
On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote:
> So the question is if one of the justifications for moving the daemon
> into kernel space is that it's performance is crap, then I think it is
> useful to determine whether a fully optimized userspace daemon would
> be good enough.
>
Yeah.
On Tue, Apr 28, 2015 at 1:19 PM, David Lang wrote:
> If the examples that are being used to show the performance advantage of
> kdbus vs normal dbus are doing the wrong thing, then we need to get some
> other examples available to people who don't live and breath dbus that 'so
> things right' so
On Tue, 28 Apr 2015, Havoc Pennington wrote:
btw if I can make a suggestion, it's quite confusing to talk about
"dbus" unqualified when we are talking about implementation issues,
since it muddles bus daemon vs. clients, and also since there are lots
of implementations of the client bindings:
On Tue, Apr 28, 2015 at 10:48:10AM -0400, Havoc Pennington wrote:
> btw if I can make a suggestion, it's quite confusing to talk about
> "dbus" unqualified when we are talking about implementation issues,
> since it muddles bus daemon vs. clients, and also since there are lots
> of implementations
btw if I can make a suggestion, it's quite confusing to talk about
"dbus" unqualified when we are talking about implementation issues,
since it muddles bus daemon vs. clients, and also since there are lots
of implementations of the client bindings:
On Mon, Apr 27, 2015 at 6:14 PM, Linus Torvalds
wrote:
> The real problems seem to be in dbus memory management (suggestion:
> keep a small per-thread cache of those message allocations) and to a
> smaller degree in the crazy utf8 validation (why the f*ck does it do
> that anyway?), with some
On Mon, Apr 27, 2015 at 6:00 PM, Linus Torvalds
wrote:
> If somebody wants to speed up dbus, they should likely look at the
> user-space code, not the kernel side.
To be more precise, your profile seems to show a lot of the gdbus
(glib bindings) user space code. (And the blocking version of this
On 04/28/2015 12:29 AM, David Lang wrote:
> On Mon, 27 Apr 2015, Lukasz Skalski wrote:
>
> aren't we being told that part of the reason for needing kdbus is that
> thousands, or tens of thousands of messages are being spewed out? how
> does limiting it to 128 messages represent real-life if this
On 04/27/2015 11:32 PM, Linus Torvalds wrote:
> On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
>>
>> To perform tests I've created two simple apps:
>>
>> - server: http://fpaste.org/215157/
>> - client: http://fpaste.org/215156/
>
> So since Andy reported that dbus seems to be a few
On 04/27/2015 10:08 PM, Andy Lutomirski wrote:
> On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
>> Hi All,
>>
>> On 04/23/2015 07:16 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Apr 23, 2015 at 09:46:22AM -0700, Andy Lutomirski wrote:
- There's still an open performance question.
On Mon, Apr 27, 2015 at 6:14 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
The real problems seem to be in dbus memory management (suggestion:
keep a small per-thread cache of those message allocations) and to a
smaller degree in the crazy utf8 validation (why the f*ck does it do
On 04/28/2015 12:29 AM, David Lang wrote:
On Mon, 27 Apr 2015, Lukasz Skalski wrote:
aren't we being told that part of the reason for needing kdbus is that
thousands, or tens of thousands of messages are being spewed out? how
does limiting it to 128 messages represent real-life if this is
Havoc == Havoc Pennington h...@pobox.com writes:
Havoc On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o ty...@mit.edu wrote:
So the question is if one of the justifications for moving the daemon
into kernel space is that it's performance is crap, then I think it is
useful to determine whether a
On Tue, Apr 28, 2015 at 7:12 PM, John Stoffel j...@stoffel.org wrote:
Havoc Yeah. I don't know how you answer that, because the answer is
Havoc probably it would be good enough for some things and not for
Havoc other things. It depends on whether an app is sending enough
Havoc data to be too
On Mon, Apr 27, 2015 at 6:00 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
If somebody wants to speed up dbus, they should likely look at the
user-space code, not the kernel side.
To be more precise, your profile seems to show a lot of the gdbus
(glib bindings) user space code. (And
btw if I can make a suggestion, it's quite confusing to talk about
dbus unqualified when we are talking about implementation issues,
since it muddles bus daemon vs. clients, and also since there are lots
of implementations of the client bindings:
On Tue, 28 Apr 2015, Havoc Pennington wrote:
On Tue, Apr 28, 2015 at 1:19 PM, David Lang da...@lang.hm wrote:
If the examples that are being used to show the performance advantage of
kdbus vs normal dbus are doing the wrong thing, then we need to get some
other examples available to people who
On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o ty...@mit.edu wrote:
So the question is if one of the justifications for moving the daemon
into kernel space is that it's performance is crap, then I think it is
useful to determine whether a fully optimized userspace daemon would
be good enough.
On Tue, Apr 28, 2015 at 12:19 PM, Havoc Pennington h...@pobox.com wrote:
From what I can tell, the core performance claim for kdbus is that for
a userspace daemon to be a routing intermediary, it has to receive and
re-send messages. If the baseline performance of IPC is the cost to
send once
On Tue, Apr 28, 2015 at 1:34 PM, David Lang da...@lang.hm wrote:
On Tue, 28 Apr 2015, Havoc Pennington wrote:
On Tue, Apr 28, 2015 at 1:19 PM, David Lang da...@lang.hm wrote:
If the examples that are being used to show the performance advantage of
kdbus vs normal dbus are doing the wrong
On Tue, Apr 28, 2015 at 10:48:10AM -0400, Havoc Pennington wrote:
btw if I can make a suggestion, it's quite confusing to talk about
dbus unqualified when we are talking about implementation issues,
since it muddles bus daemon vs. clients, and also since there are lots
of implementations of
On Tue, 28 Apr 2015, Havoc Pennington wrote:
btw if I can make a suggestion, it's quite confusing to talk about
dbus unqualified when we are talking about implementation issues,
since it muddles bus daemon vs. clients, and also since there are lots
of implementations of the client bindings:
On 04/27/2015 10:08 PM, Andy Lutomirski wrote:
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski l.skal...@samsung.com wrote:
Hi All,
On 04/23/2015 07:16 PM, Greg Kroah-Hartman wrote:
On Thu, Apr 23, 2015 at 09:46:22AM -0700, Andy Lutomirski wrote:
- There's still an open performance
On 04/27/2015 11:32 PM, Linus Torvalds wrote:
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski l.skal...@samsung.com wrote:
To perform tests I've created two simple apps:
- server: http://fpaste.org/215157/
- client: http://fpaste.org/215156/
So since Andy reported that dbus seems to be a
On Tue, Apr 28, 2015 at 1:19 PM, David Lang da...@lang.hm wrote:
If the examples that are being used to show the performance advantage of
kdbus vs normal dbus are doing the wrong thing, then we need to get some
other examples available to people who don't live and breath dbus that 'so
things
On Mon, 27 Apr 2015, Lukasz Skalski wrote:
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote:
On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
On 04/24/2015 04:19 PM, Havoc Pennington wrote:
On Fri, Apr 24, 2015 at 9:50 AM, Lukasz
On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds
wrote:
>
> IOW, all the people who say that it's about avoiding context switches
> are probably just full of shit. It's not about context switches, it's
> about bad user-level code.
Just to make sure, I did a system-wide profile (so that you can
On Mon, Apr 27, 2015 at 2:40 PM, Andy Lutomirski wrote:
>
> Change "USER" to "SESSION".
That works.
> Build with:
Hell no. I used
gcc client.c -o client $(pkg-config --cflags --libs gtk+-2.0)
instead. That worked.
>> That said, either you're running your test on a potato, or dbus is
>>
On Mon, Apr 27, 2015 at 2:32 PM, Linus Torvalds
wrote:
> On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
>>
>> To perform tests I've created two simple apps:
>>
>> - server: http://fpaste.org/215157/
>> - client: http://fpaste.org/215156/
>
> So since Andy reported that dbus seems to be a
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
>
> To perform tests I've created two simple apps:
>
> - server: http://fpaste.org/215157/
> - client: http://fpaste.org/215156/
So since Andy reported that dbus seems to be a few orders of magnitude
too slow, I tried to build these apps to
[resent without HTML]
On Apr 27, 2015 5:46 AM, "Michal Hocko" wrote:
>
> On Wed 22-04-15 12:36:12, Andy Lutomirski wrote:
> > On Apr 22, 2015 7:57 AM, "Michal Hocko" wrote:
> > >
> > > On Tue 21-04-15 11:11:35, Andy Lutomirski wrote:
> > > > On Tue, Apr 21, 2015 at 7:27 AM, Michal Hocko wrote:
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski wrote:
> Hi All,
>
> On 04/23/2015 07:16 PM, Greg Kroah-Hartman wrote:
>> On Thu, Apr 23, 2015 at 09:46:22AM -0700, Andy Lutomirski wrote:
>>> - There's still an open performance question. Namely: is kdbus performant?
>>
>> Yes, I thought that was
On Mon, Apr 27, 2015 at 10:57:45AM +0200, Lukasz Skalski wrote:
> On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote:
> > On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
> >> On 04/24/2015 04:19 PM, Havoc Pennington wrote:
> >>> On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski
> >>>
Hi
On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski wrote:
from the client that accesses a service. The client asks a service
provider to perform an action. The service provider then asks the
authorization-framework, whether the client is authorized to run the
action.
>>>
>>>
On Mon, Apr 27, 2015 at 8:50 AM, David Herrmann wrote:
> Hi
>
> On Mon, Apr 27, 2015 at 4:57 PM, One Thousand Gnomes
> wrote:
>>> But this is not how authorization with polkit works (or anything
>>> similar to polkit). The authorization-framework is totally separated
>>
>> Thats a detail which
Hi
On Mon, Apr 27, 2015 at 4:57 PM, One Thousand Gnomes
wrote:
>> But this is not how authorization with polkit works (or anything
>> similar to polkit). The authorization-framework is totally separated
>
> Thats a detail which is changeable
It's not a detail, it's a design choice. But see at
> But this is not how authorization with polkit works (or anything
> similar to polkit). The authorization-framework is totally separated
Thats a detail which is changeable
> from the client that accesses a service. The client asks a service
> provider to perform an action. The service provider
On Thu, Apr 23, 2015 at 12:41:18PM -0700, Andy Lutomirski wrote:
> On Thu, Apr 23, 2015 at 11:48 AM, Linus Torvalds
> wrote:
> > On Thu, Apr 23, 2015 at 10:57 AM, Linus Torvalds
[...]
> Objection 2: There's a difference between the printer daemon knowing
> that Angry Penguins has general
On Wed 22-04-15 12:36:12, Andy Lutomirski wrote:
> On Apr 22, 2015 7:57 AM, "Michal Hocko" wrote:
> >
> > On Tue 21-04-15 11:11:35, Andy Lutomirski wrote:
> > > On Tue, Apr 21, 2015 at 7:27 AM, Michal Hocko wrote:
> > > > On Tue 21-04-15 16:01:01, David Herrmann wrote:
> > > >> Hi
> > > >>
> > >
On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote:
> On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
>> On 04/24/2015 04:19 PM, Havoc Pennington wrote:
>>> On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski
>>> wrote:
- client: http://fpaste.org/215156/
>>>
>>> Cool - it
Hi
On Fri, Apr 24, 2015 at 12:08 AM, Andy Lutomirski wrote:
> Enter kdbus. We now have an unbounded number of possible kdbus calls,
> and somehow users are supposed to keep track of which privileges the
> hold affect which kdbus calls. Either each method should document
> which privileges it
[resent without HTML]
On Apr 27, 2015 5:46 AM, Michal Hocko mho...@suse.cz wrote:
On Wed 22-04-15 12:36:12, Andy Lutomirski wrote:
On Apr 22, 2015 7:57 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 21-04-15 11:11:35, Andy Lutomirski wrote:
On Tue, Apr 21, 2015 at 7:27 AM, Michal
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski l.skal...@samsung.com wrote:
Hi All,
On 04/23/2015 07:16 PM, Greg Kroah-Hartman wrote:
On Thu, Apr 23, 2015 at 09:46:22AM -0700, Andy Lutomirski wrote:
- There's still an open performance question. Namely: is kdbus performant?
Yes, I thought
On Mon, Apr 27, 2015 at 2:32 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski l.skal...@samsung.com wrote:
To perform tests I've created two simple apps:
- server: http://fpaste.org/215157/
- client: http://fpaste.org/215156/
So since
On Fri, Apr 24, 2015 at 6:50 AM, Lukasz Skalski l.skal...@samsung.com wrote:
To perform tests I've created two simple apps:
- server: http://fpaste.org/215157/
- client: http://fpaste.org/215156/
So since Andy reported that dbus seems to be a few orders of magnitude
too slow, I tried to
On Mon, Apr 27, 2015 at 2:40 PM, Andy Lutomirski l...@amacapital.net wrote:
Change USER to SESSION.
That works.
Build with:
Hell no. I used
gcc client.c -o client $(pkg-config --cflags --libs gtk+-2.0)
instead. That worked.
That said, either you're running your test on a potato, or
On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote:
On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
On 04/24/2015 04:19 PM, Havoc Pennington wrote:
On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski l.skal...@samsung.com
wrote:
- client: http://fpaste.org/215156/
Cool - it
Hi
On Fri, Apr 24, 2015 at 12:08 AM, Andy Lutomirski l...@amacapital.net wrote:
Enter kdbus. We now have an unbounded number of possible kdbus calls,
and somehow users are supposed to keep track of which privileges the
hold affect which kdbus calls. Either each method should document
which
On Wed 22-04-15 12:36:12, Andy Lutomirski wrote:
On Apr 22, 2015 7:57 AM, Michal Hocko mho...@suse.cz wrote:
On Tue 21-04-15 11:11:35, Andy Lutomirski wrote:
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 Thu, Apr 23, 2015 at 12:41:18PM -0700, Andy Lutomirski wrote:
On Thu, Apr 23, 2015 at 11:48 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Apr 23, 2015 at 10:57 AM, Linus Torvalds
[...]
Objection 2: There's a difference between the printer daemon knowing
that Angry
But this is not how authorization with polkit works (or anything
similar to polkit). The authorization-framework is totally separated
Thats a detail which is changeable
from the client that accesses a service. The client asks a service
provider to perform an action. The service provider then
On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
IOW, all the people who say that it's about avoiding context switches
are probably just full of shit. It's not about context switches, it's
about bad user-level code.
Just to make sure, I did a system-wide
On Mon, 27 Apr 2015, Lukasz Skalski wrote:
Subject: Re: [GIT PULL] kdbus for 4.1-rc1
On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote:
On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
On 04/24/2015 04:19 PM, Havoc Pennington wrote:
On Fri, Apr 24, 2015 at 9:50 AM, Lukasz
Hi
On Mon, Apr 27, 2015 at 4:57 PM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
But this is not how authorization with polkit works (or anything
similar to polkit). The authorization-framework is totally separated
Thats a detail which is changeable
It's not a detail, it's a design
On Mon, Apr 27, 2015 at 8:50 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Mon, Apr 27, 2015 at 4:57 PM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
But this is not how authorization with polkit works (or anything
similar to polkit). The authorization-framework is totally
Hi
On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski l...@amacapital.net wrote:
from the client that accesses a service. The client asks a service
provider to perform an action. The service provider then asks the
authorization-framework, whether the client is authorized to run the
action.
On Mon, Apr 27, 2015 at 10:57:45AM +0200, Lukasz Skalski wrote:
On 04/24/2015 09:25 PM, Greg Kroah-Hartman wrote:
On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
On 04/24/2015 04:19 PM, Havoc Pennington wrote:
On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski
Linus wrote:
> It would be insane to say that the open system call should have an
> explicit argument saying that the vfs layer should take your privileges
> into account.
On the contrary, it would be a big improvement on the current interface.
To be clearer, it would be great if the open system
Linus wrote:
It would be insane to say that the open system call should have an
explicit argument saying that the vfs layer should take your privileges
into account.
On the contrary, it would be a big improvement on the current interface.
To be clearer, it would be great if the open system
On Fri, Apr 24, 2015 at 04:34:34PM +0200, Lukasz Skalski wrote:
> On 04/24/2015 04:19 PM, Havoc Pennington wrote:
> > On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski
> > wrote:
> >> - client: http://fpaste.org/215156/
> >>
> >
> > Cool - it might also be interesting to try this without blocking
On 04/24/2015 04:19 PM, Havoc Pennington wrote:
> On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski wrote:
>> - client: http://fpaste.org/215156/
>>
>
> Cool - it might also be interesting to try this without blocking round
> trips, i.e. send requests as quickly as you can, and collect replies
>
On Fri, Apr 24, 2015 at 9:50 AM, Lukasz Skalski wrote:
> - client: http://fpaste.org/215156/
>
Cool - it might also be interesting to try this without blocking round
trips, i.e. send requests as quickly as you can, and collect replies
asynchronously. That's how people ideally use dbus. It should
On Thu, Apr 23, 2015 at 11:33:19PM +0200, Richard Weinberger wrote:
> > No it's not. O(256) equals O(1).
>
> Yeah, that's absolutely correct.
> I think Boris wanted to say that iterating over all hash buckets
> can be costly.
You are thinking of 'k' (the constant), where you usually have k*O(1),
Hi All,
On 04/23/2015 07:16 PM, Greg Kroah-Hartman wrote:
> On Thu, Apr 23, 2015 at 09:46:22AM -0700, Andy Lutomirski wrote:
>> - There's still an open performance question. Namely: is kdbus performant?
>
> Yes, I thought that was already answered. Tizen posted some numbers
> with a much
Hi,
On 04/24/2015 12:50 PM, Borislav Petkov wrote:
> On Fri, Apr 24, 2015 at 12:28:54PM +0200, Daniel Mack wrote:
>> Sure, for broadcasts, we have to walk the list of peers connected to the
>> bus and see which one is interested in a particular message. We do that
>
> And this "... we have to
101 - 200 of 698 matches
Mail list logo
