On Mon, Apr 27, 2015 at 03:14:49PM -0700, Linus Torvalds wrote:
> 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
On Mon, Apr 27, 2015 at 03:14:49PM -0700, Linus Torvalds wrote:
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
2015-04-30 22:52 GMT+08:00 Łukasz Stelmach :
> It was <2015-04-30 czw 14:45>, when Richard Weinberger wrote:
>> Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
>>> It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
> It was
2015-04-30 22:52 GMT+08:00 Łukasz Stelmach l.stelm...@samsung.com:
It was 2015-04-30 czw 14:45, when Richard Weinberger wrote:
Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 14:23, when Richard Weinberger wrote:
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
It was
On Mon, 27 Apr 2015 15:14:49 -0700
Linus Torvalds wrote:
> 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
On Mon, 22 Jun 2015, Jindrich Makovicka 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
On Mon, 27 Apr 2015 15:14:49 -0700, Linus Torvalds wrote:
> 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.
On Mon, 27 Apr 2015 15:14:49 -0700, Linus Torvalds wrote:
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
On Mon, 27 Apr 2015 15:14:49 -0700
Linus Torvalds torva...@linux-foundation.org wrote:
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
On Mon, 22 Jun 2015, Jindrich Makovicka 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 actually
On Fri, May 1, 2015 at 9:48 PM, Andy Lutomirski wrote:
> Havoc, am I missing something here? If I'm right about this aspect of
> D-Bus, then I'm a bit surprised.
>
I'm not well-informed about Binder, though from reading about it, it
seems to be modeled on and comparable to COM.
>From what I
On Fri, May 1, 2015 at 9:48 PM, Andy Lutomirski l...@amacapital.net wrote:
Havoc, am I missing something here? If I'm right about this aspect of
D-Bus, then I'm a bit surprised.
I'm not well-informed about Binder, though from reading about it, it
seems to be modeled on and comparable to COM.
On Mon, Apr 27, 2015 at 9:33 AM, David Herrmann wrote:
> On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski wrote:
>> 2. This is a nice thought, but it doesn't work in practice. Sorry.
>> I can give you a big pile of CVEs from last year if you like, or I can
>> try explaining again.
>>
>> The
On 2015-04-29 08:47, Harald Hoyer wrote:
Until then the whole common IPC problem is unresolved and Linux
distributions are just a collection of random software with no common
interoperability and home grown interfaces.
I don't know how I managed to not notice this comment before, but I find
it
On Mon, Apr 27, 2015 at 9:33 AM, David Herrmann dh.herrm...@gmail.com wrote:
On Mon, Apr 27, 2015 at 6:13 PM, Andy Lutomirski l...@amacapital.net wrote:
2. This is a nice thought, but it doesn't work in practice. Sorry.
I can give you a big pile of CVEs from last year if you like, or I can
On 2015-04-29 08:47, Harald Hoyer wrote:
Until then the whole common IPC problem is unresolved and Linux
distributions are just a collection of random software with no common
interoperability and home grown interfaces.
I don't know how I managed to not notice this comment before, but I find
it
On April 29, 2015 7:47:53 AM CDT, Harald Hoyer 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 candidate
Am 30.04.2015 um 16:52 schrieb Łukasz Stelmach:
>> Sorry, I thought you mean the races while collecting metadata in userspace...
>
> My bad, some reace conditions *are* associated with collecting metadata
> but ont all. It is impossible (correct me if I am wrong) to implement
> reliable
It was <2015-04-30 czw 14:45>, when Richard Weinberger wrote:
> Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
>> It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
>>> Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
> It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
>> Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
>>> It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
> It was
It was <2015-04-30 czw 14:23>, when Richard Weinberger wrote:
> Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
>> It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
>>> Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
> It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
>> Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
>>> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
>
It was <2015-04-30 czw 12:40>, when Richard Weinberger wrote:
> Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
>> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
>>> Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
Regardless, of initrd issues I feel there is a need of a local
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
> It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
>> Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
>>> Regardless, of initrd issues I feel there is a need of a local IPC
>>> that is more capable than UDS. Linus Torvalds is probably
It was <2015-04-30 czw 11:12>, when Richard Weinberger wrote:
> Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
>> Regardless, of initrd issues I feel there is a need of a local IPC
>> that is more capable than UDS. Linus Torvalds is probably right that
>> dbus-daemon is everything but effictient.
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
> Regardless, of initrd issues I feel there is a need of a local IPC that
> is more capable than UDS. Linus Torvalds is probably right that
> dbus-daemon is everything but effictient. I disagree, however, that it
> can be optimised and therefore
It was <2015-04-29 śro 17:21>, when Austin S Hemmelgarn wrote:
> 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
It was 2015-04-29 śro 17:21, when Austin S Hemmelgarn wrote:
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
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
Regardless, of initrd issues I feel there is a need of a local IPC that
is more capable than UDS. Linus Torvalds is probably right that
dbus-daemon is everything but effictient. I disagree, however, that it
can be optimised and therefore solve
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 11:12, when Richard Weinberger wrote:
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
Regardless, of initrd issues I feel there is a need of a local IPC
that is more capable than UDS. Linus Torvalds is probably right that
It was 2015-04-30 czw 11:12, when Richard Weinberger wrote:
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
Regardless, of initrd issues I feel there is a need of a local IPC
that is more capable than UDS. Linus Torvalds is probably right that
dbus-daemon is everything but effictient. I
It was 2015-04-30 czw 12:40, when Richard Weinberger wrote:
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 11:12, when Richard Weinberger wrote:
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
Regardless, of initrd issues I feel there is a need of a local IPC
that is
Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 14:23, when Richard Weinberger wrote:
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 12:40, when Richard Weinberger wrote:
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 11:12,
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 12:40, when Richard Weinberger wrote:
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 11:12, when Richard Weinberger wrote:
Am 30.04.2015 um 11:05 schrieb Łukasz Stelmach:
Regardless, of initrd issues
It was 2015-04-30 czw 14:23, when Richard Weinberger wrote:
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 12:40, when Richard Weinberger wrote:
Am 30.04.2015 um 12:19 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 11:12, when Richard Weinberger wrote:
Am 30.04.2015 um
Am 30.04.2015 um 16:52 schrieb Łukasz Stelmach:
Sorry, I thought you mean the races while collecting metadata in userspace...
My bad, some reace conditions *are* associated with collecting metadata
but ont all. It is impossible (correct me if I am wrong) to implement
reliable die-on-idle
On April 29, 2015 7:47:53 AM CDT, 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
It was 2015-04-30 czw 14:45, when Richard Weinberger wrote:
Am 30.04.2015 um 14:40 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 14:23, when Richard Weinberger wrote:
Am 30.04.2015 um 14:16 schrieb Łukasz Stelmach:
It was 2015-04-30 czw 12:40, when Richard Weinberger wrote:
Am 30.04.2015 um
> "David" == David Herrmann writes:
David> Hi
David> On Wed, Apr 29, 2015 at 10:43 PM, David Lang 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> It's not.
>> the
>>>
>>> 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
On Thu, 30 Apr 2015, Dave Airlie wrote:
On 30 April 2015 at 10:05, David Lang 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
On 30 April 2015 at 10:05, David Lang 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
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 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
> "Austin" == Austin S Hemmelgarn writes:
Austin> On 2015-04-29 14:54, Andy Lutomirski wrote:
>> On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
>>>
>>> * Being in the kernel closes a lot of races which can't be fixed with
>>> the current userspace solutions. For example, with kdbus, there
On Fri, Apr 24, 2015 at 4:08 AM, Karol Lewandowski
wrote:
> On Thu, Apr 23, 2015 at 09:30:13PM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Apr 23, 2015 at 01:42:25PM -0400, Stephen Smalley wrote:
>> > On 04/23/2015 01:16 PM, Greg Kroah-Hartman wrote:
>> > > The binder developers at Samsung have
Hi
On Wed, Apr 29, 2015 at 10:43 PM, David Lang 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 messages
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 1:15 PM, David Lang wrote:
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
wrote:
On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, "Harald Hoyer"
On Wed, Apr 29, 2015 at 1:15 PM, David Lang wrote:
> On Wed, 29 Apr 2015, Andy Lutomirski wrote:
>
>> On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
>> wrote:
>>>
>>> On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
>
>
On Wed, 29 Apr 2015, Andy Lutomirski wrote:
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
wrote:
On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
* Being in the kernel closes a lot of races which can't be fixed with
the current
On Wed, Apr 29, 2015 at 12:30 PM, Austin S Hemmelgarn
wrote:
> On 2015-04-29 14:54, Andy Lutomirski wrote:
>>
>> On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
>>>
>>>
>>> * Being in the kernel closes a lot of races which can't be fixed with
>>> the current userspace solutions. For
On 2015-04-29 14:54, Andy Lutomirski wrote:
On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
* Being in the kernel closes a lot of races which can't be fixed with
the current userspace solutions. For example, with kdbus, there is a
way a client can disconnect from a bus, but do so
> "Steven" == Steven Rostedt writes:
Steven> 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?
Am Mittwoch, 29. April 2015, 13:39:42 schrieb Steven Rostedt:
> 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
On Apr 29, 2015 5:48 AM, "Harald Hoyer" wrote:
> Of course this can all be done, but it would involve fallback mechanisms,
> which we want to get rid off. Hopefully, you don't suggest to merge dbus with
> PID 1. Also with a daemon, you will lose the points mentioned in the cover
> mail
> :
>
>
Am Mittwoch, 29. April 2015, 17:22:08 schrieb Harald Hoyer:
> 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
On 04/29/2015 11:18 AM, Simon McVittie wrote:
> On 29/04/15 14:35, Stephen Smalley wrote:
>> It is also interesting that kdbus allows impersonation of any
>> credential, including security label, by "privileged" clients, where
>> privileged simply means it either has CAP_IPC_OWNER or owns (euid
>>
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 Mon 27-04-15 13:11:03, Andy Lutomirski wrote:
> [resent without HTML]
>
> On Apr 27, 2015 5:46 AM, "Michal Hocko" wrote:
> >
> > On Wed 22-04-15 12:36:12, Andy Lutomirski wrote:
[...]
> > > The receiver gets to mmap the buffer. I'm not sure what protection they
> > > get.
> >
> > OK, so
On Wed, 29 Apr 2015, Martin Steigerwald wrote:
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
> "Harald" == Harald Hoyer writes:
Harald> 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
Am Mittwoch, 29. April 2015, 11:03:41 schrieb Theodore Ts'o:
> 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
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
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
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
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 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,
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
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 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
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
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
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 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
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
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
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
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
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
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
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
On Wed, Apr 29, 2015 at 2:47 PM, Harald Hoyer 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 candidate for
-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 candidate for going
> into the kernel? And why is kdbus so important in the
On 29.04.2015 01:12, John Stoffel wrote:
>> "Havoc" == Havoc Pennington writes:
>
> Havoc> On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o wrote:
>>> I find dbus to be extremely hard to debug when my desktop starts doing
>>> things I don't want it to do. The fact that it might be flinging
On 29.04.2015 01:12, John Stoffel wrote:
Havoc == Havoc Pennington h...@pobox.com writes:
Havoc On Tue, Apr 28, 2015 at 1:18 PM, Theodore Ts'o ty...@mit.edu wrote:
I find dbus to be extremely hard to debug when my desktop starts doing
things I don't want it to do. The fact that it might be
-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 candidate for going
into the kernel? And why is kdbus so important in the
Am Mittwoch, 29. April 2015, 11:03:41 schrieb Theodore Ts'o:
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_
On Wed, 29 Apr 2015, Martin Steigerwald wrote:
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
Harald == Harald Hoyer har...@redhat.com writes:
Harald 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
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 har...@redhat.com wrote:
* Being in the kernel closes a lot of races which
On Mon 27-04-15 13:11:03, Andy Lutomirski wrote:
[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:
[...]
The receiver gets to mmap the buffer. I'm not sure what protection they
get.
OK, so I've
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
Steven == Steven Rostedt rost...@goodmis.org writes:
Steven 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?
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, with kdbus, there is a
way a client can disconnect from a
Am Mittwoch, 29. April 2015, 13:39:42 schrieb Steven Rostedt:
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?
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 har...@redhat.com wrote:
* Being in the kernel closes a lot of races which can't be fixed with
the current userspace
On Apr 29, 2015 5:48 AM, Harald Hoyer har...@redhat.com wrote:
Of course this can all be done, but it would involve fallback mechanisms,
which we want to get rid off. Hopefully, you don't suggest to merge dbus with
PID 1. Also with a daemon, you will lose the points mentioned in the cover
On 04/29/2015 11:18 AM, Simon McVittie wrote:
On 29/04/15 14:35, Stephen Smalley wrote:
It is also interesting that kdbus allows impersonation of any
credential, including security label, by privileged clients, where
privileged simply means it either has CAP_IPC_OWNER or owns (euid
matches
Am Mittwoch, 29. April 2015, 17:22:08 schrieb Harald Hoyer:
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
On Fri, Apr 24, 2015 at 4:08 AM, Karol Lewandowski
karol.k.lewandow...@gmail.com wrote:
On Thu, Apr 23, 2015 at 09:30:13PM +0200, Greg Kroah-Hartman wrote:
On Thu, Apr 23, 2015 at 01:42:25PM -0400, Stephen Smalley wrote:
On 04/23/2015 01:16 PM, Greg Kroah-Hartman wrote:
The binder
1 - 100 of 698 matches
Mail list logo
