On 10/28/2013 7:31 PM, Andrey Wagin wrote:
> I had experience of implementing this functionality in OpenVZ kernel.
> I had requirements to not modify user-space tools, so that
> implementations looks as dirty hack, but even hotplug of devices are
> workin there.
Same here. I want the container
2013/9/26 Eric W. Biederman
>
>
> From conversations at Linux Plumbers Converence it became fairly clear
> that one if not the roughest edge on containers today is dealing with
> devices.
>
> - Hotplug does not work.
> - There seems to be no implementation that does a much beyond creating
> sett
Amir Goldstein writes:
> Excellent! let's focus the discussion on a new device driver we want
> to write
> which is namespace aware. let's call this device driver valarm-dev.
> Similarly to Android's alarm-dev, valarm-dev can be used to request
> RTC wakeup calls
> from user space and get/set RTC
On Thu, Oct 3, 2013 at 3:44 AM, Eric W. Biederman wrote:
> Amir Goldstein writes:
>
> > What we really like to see is a setns() style API that can be used to
> > add a device in the context of a namespace in either a "shared" or
> > "private" mode.
>
> I think you mean an "ip link set dev FOO net
ebied...@xmission.com (Eric W. Biederman) writes:
>> This kind of API is a required building block for us to write device
>> drivers that are namespace aware in a way that userspace will have
>> enough flexibility for dynamic configuration.
>>
>> We are trying to come up with a proposal for that s
Amir Goldstein writes:
> What we really like to see is a setns() style API that can be used to
> add a device in the context of a namespace in either a "shared" or
> "private" mode.
I think you mean an "ip link set dev FOO netns XXX" style API.
Right now one of the best suggestions on the table
Serge Hallyn writes:
>> Glossing over the details. The general problem is some policy exists
>> outside of the container that deciedes if an when a container gets a
>> serial port and stuffs it in.
>>
>> The expectation is that system containers will then run the udev
>> rules and send the libu
I think libudev is a solution to a completely different problem. It is
possible I am blind but I just don't see how libudev even attempts to
solve the problem.
The desire is to plop a distro install into a subdirectory. Fire up a
container around it, and let the distro's userspace do it's thing
On Tue, 2013-10-01 at 15:46 -0500, Serge Hallyn wrote:
> Quoting Eric W. Biederman (ebied...@xmission.com):
> > "Serge E. Hallyn" writes:
> >
> > > Quoting Andy Lutomirski (l...@amacapital.net):
> > >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen
> > >> wrote:
> > >> > On Thu, Sep 26, 2013 a
On 10/1/2013 4:46 PM, Serge Hallyn wrote:
> I thought the suggestion was that udev on the host would be given
> container-specific rules, saying "plop this device into /dev/container1/"
> (with /dev/container1 being bind-mounted to $container1_rootfs/dev).
>
> -serge
At least for my use case this i
On Tue, 2013-10-01 at 12:51 -0700, Eric W. Biederman wrote:
> "Serge E. Hallyn" writes:
>
> > Quoting Andy Lutomirski (l...@amacapital.net):
> >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen
> >> wrote:
> >> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> >> > wrote:
> >> >
> >> >>>
On Tue, Oct 01, 2013 at 12:51:36PM -0700, Eric W. Biederman wrote:
> "Serge E. Hallyn" writes:
>
> > Quoting Andy Lutomirski (l...@amacapital.net):
> >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen
> >> wrote:
> >> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> >> > wrote:
> >> >
>
Quoting Eric W. Biederman (ebied...@xmission.com):
> "Serge E. Hallyn" writes:
>
> > Quoting Andy Lutomirski (l...@amacapital.net):
> >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen
> >> wrote:
> >> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> >> > wrote:
> >> >
> >> >>> - We can
"Serge E. Hallyn" writes:
> Quoting Andy Lutomirski (l...@amacapital.net):
>> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen
>> wrote:
>> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
>> > wrote:
>> >
>> >>> - We can relay a call of /sbin/hotplug from outside of a container
>> >>> to
On Tue, Oct 1, 2013 at 8:27 PM, Andy Lutomirski wrote:
>> http://lists.linuxfoundation.org/pipermail/containers/2013-May/032591.html
>
> Can't the daemon live outside the container and shuffle stuff in?
> IOW, there seems to be little point in containerizing things if you're
> just going to punch
Quoting Andy Lutomirski (l...@amacapital.net):
> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen
> wrote:
> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> > wrote:
> >
> >>> - We can relay a call of /sbin/hotplug from outside of a container
> >>> to inside of a container based on polic
On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen wrote:
> On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> wrote:
>
>>> - We can relay a call of /sbin/hotplug from outside of a container
>>> to inside of a container based on policy.
>>> (But no one uses /sbin/hotplug anymore).
>>
>> That's
On Tue, Oct 1, 2013 at 8:33 PM, Greg Kroah-Hartman
wrote:
>> > That's right, they should be listening to libudev events, so why can't
>> > your daemon shuffle them off to the proper container, all in userspace?
>>
>> Which reminds me, one potential reason being..
>> http://lists.linuxfoundation.o
On Tue, Oct 01, 2013 at 09:19:58AM +0300, Janne Karhunen wrote:
> On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> wrote:
>
> >> - We can relay a call of /sbin/hotplug from outside of a container
> >> to inside of a container based on policy.
> >> (But no one uses /sbin/hotplug anymore).
On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
wrote:
>> - We can relay a call of /sbin/hotplug from outside of a container
>> to inside of a container based on policy.
>> (But no one uses /sbin/hotplug anymore).
>
> That's right, they should be listening to libudev events, so why can't
On Mon, 2013-09-30 at 09:11 -0700, Greg Kroah-Hartman wrote:
> On Mon, Sep 30, 2013 at 08:37:19AM -0700, James Bottomley wrote:
> > On Thu, 2013-09-26 at 10:07 -0700, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 26, 2013 at 08:01:31PM +0300, Janne Karhunen wrote:
> > > > That being said, our wish wo
On Thu, 2013-09-26 at 10:07 -0700, Greg Kroah-Hartman wrote:
> On Thu, Sep 26, 2013 at 08:01:31PM +0300, Janne Karhunen wrote:
> > That being said, our wish would be to support any combination of
> > OS's and frankly, I'd be slightly annoyed to tell the customer that
> > they can't do two Androids
On Mon, Sep 30, 2013 at 08:37:19AM -0700, James Bottomley wrote:
> On Thu, 2013-09-26 at 10:07 -0700, Greg Kroah-Hartman wrote:
> > On Thu, Sep 26, 2013 at 08:01:31PM +0300, Janne Karhunen wrote:
> > > That being said, our wish would be to support any combination of
> > > OS's and frankly, I'd be s
On Sun, 2013-09-29 at 13:06 -0700, Greg Kroah-Hartman wrote:
> On Sun, Sep 29, 2013 at 10:28:55PM +0300, Amir Goldstein wrote:
> >
> >
> >
> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> > > > wrote:
> >
> > On Wed, Sep 25, 2013 at 02:34:54PM -0700, Eric W. Biederman wrote:
> >
On Sun, Sep 29, 2013 at 10:28:55PM +0300, Amir Goldstein wrote:
>
>
>
> On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> > wrote:
>
> On Wed, Sep 25, 2013 at 02:34:54PM -0700, Eric W. Biederman wrote:
> > So the big issues for a device namespace to solve are filtering which
>
On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman <
gre...@linuxfoundation.org> wrote:
> On Wed, Sep 25, 2013 at 02:34:54PM -0700, Eric W. Biederman wrote:
> > So the big issues for a device namespace to solve are filtering which
> > devices a container has access to and being able to dynamicall
On Thu, Sep 26, 2013 at 8:07 PM, Greg Kroah-Hartman
wrote:
>> That being said, our wish would be to support any combination of
>> OS's and frankly, I'd be slightly annoyed to tell the customer that
>> they can't do two Androids or we magically run out of bits.
>
> If you want to support "any" com
On Thu, Sep 26, 2013 at 4:56 PM, Greg Kroah-Hartman
wrote:
>> I suppose so, but now you take the assumption that there is no
>> need for running multiple Linux variants on the same host (say
>> Ubuntu and Android side by side). Is this something you would
>> not like to see done?
>
> You can do t
On Thu, Sep 26, 2013 at 11:25:56AM +0300, Janne Karhunen wrote:
> On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> wrote:
>
> >> In summary the situation with device hoptlug and containers sucks today,
> >> and we need to do something. Running a linux desktop in a container is
> >> a reason
On Thu, Sep 26, 2013 at 08:01:31PM +0300, Janne Karhunen wrote:
> That being said, our wish would be to support any combination of
> OS's and frankly, I'd be slightly annoyed to tell the customer that
> they can't do two Androids or we magically run out of bits.
If you want to support "any" combin
As I mentioned in another part of this thread, my use case is deploying
"linux desktops" to users as containers. The goal is to have the
container run unmodified distros, and to be able to run arbitrary code.
A tall order to be sure, and maybe not realistic, but I'm in research so
its good to
On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
wrote:
>> In summary the situation with device hoptlug and containers sucks today,
>> and we need to do something. Running a linux desktop in a container is
>> a reasonably good example use case.
>
> No it isn't. I'd argue that this is a horri
On Wed, Sep 25, 2013 at 02:34:54PM -0700, Eric W. Biederman wrote:
> So the big issues for a device namespace to solve are filtering which
> devices a container has access to and being able to dynamically change
> which devices those are at run time (aka hotplug).
As _all_ devices are hotpluggable
33 matches
Mail list logo
