On Wed, Jul 27, 2011 at 12:21:09AM +0200, Tejun Heo wrote:
> On Tue, Jul 26, 2011 at 03:02:15PM -0700, Matt Helsley wrote:
> > > Sure, that was completely embedded in the kernel and things can be
> > > implemented and fixed with much less consideration. I can see how
> > > that would be easier for the specific use case, but that EXACTLY is
> > > why it can't go upstream. I just can't see it happening and think it
> >
> > It can't go upstream because it's too easy to implement and fix?
> > It can't go upstream because it has a specific use case?
> > Is there something that says every interface added to the kernel *must*
> > be useful for something besides the purpose that originally inspired it?
>
> You really don't understand what I'm trying to say at all?
That's not what I said. I know you're arguing we shouldn't have an
in-kernel implementation.
Your statement above did not seem to support your argument at all --
you seemed to be conceding that an in-kernel implementation ("embedded
in the kernel") would be easier to implement and fix (nit: would've
been nice for you to include a bit more context..).
I know you think we should make use of lots of changes in a variety
of places such as ptrace, new bits in /proc, etc. to avoid an in-kernel
implementation. That's certainly an enticingly simple (non-complex) idea.
However I still question whether the idea will work well for
checkpoint/restart.
Cheers,
-Matt Helsley
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
