Message-ID: <20150910055834.GB31213@kroah.com>
Date:	Wed, 9 Sep 2015 22:58:34 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Amir Goldstein <amir@...lrox.com>
Cc:	Michael J Coss <michael.coss@...atel-lucent.com>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	containers@...ts.linuxfoundation.org, davem@...emloft.net,
	linux-kernel@...r.kernel.org, Oren Laadan <orenl@...lrox.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Stephane Graber <stgraber@...ntu.com>
Subject: Re: [PATCH 2/3] lib/kobject_uevent.c: add uevent forwarding function

On Thu, Sep 10, 2015 at 08:43:28AM +0300, Amir Goldstein wrote:
> I fully agree with you that running unmodified distro inside a
> container is not a justified
> cause for kernel changes.

Great, end of discussion :)

> However, I would like to highlight the point that udev is not the only
> consumer of uevents, so changing userspace, as you rightfully
> suggested, may not be as simple as you imagine.

But you have control over who consumes uevents, so if you really want to
create such a "only send some uevents to some containers" you can do so
from the "host" container today.  Exactly like udev does this today if
you look at how udevd works, udevd uses the kernel as the filter to only
wake up processes that have subscribed to specific events.  It's as if
no one actually looks at how this works :(

> For example, in our Android use case, we have no intention of running
> unmodified Android
> inside container and modifying Android's ueventd is not an issue for us.
> Android userspace uses uevents extensively. For example, vold uses uevents to be
> notified of SDCARD insert event and that is just one example.
> We can get around vold and maybe we can get around every other open
> source Android tool
> that make use of uevents, but phone vendors tend to use uevents to communicate
> messages between their drivers and proprietary software and this is
> were we must have
> a way to filter those uevents in the kernel.

If you are going to modify Android, just use udevd and filter things
that way, you can do it today.  Or just modify the tools that Android
uses for listening to uevents.

> You argue that "device is never bound to a namespace" (and that it
> never will be) and I don't disagree with that.

Great, end of discussion :)

> However, as Eric said, the "broadcast everything" logic does not make
> much sense.

Only one thing is listening to these events, put your filter there
(again, just like udevd does today...)

> In a way, the broadcast logic is opposite to your suggestion to modify
> userspace.

Nope, see above.

> In almost every existing implementation of containers, only the root namespace
> owns responsibility for booting the machine and configuring devices, so if all
> containers were running modified userspace, there would have been no need to
> broadcast uevents to all namespaces.

Wonderful, as you said you were going to modify the container
applications, this isn't an issue :)

> At the very least, you should be able to consent with the idea of
> having the broadcast policy decided by userspace.

But it already is, userspace can decide what it wants to do with every
event today.  Again, to sound like a broken record, just like udevd
does.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists