linux-kernel - Re: [RFC v2][PATCH 4/9] Memory management

Open Source and information security mailing list archives

Date:	Sun, 31 Aug 2008 03:16:31 -0400
From:	Oren Laadan <orenl@...columbia.edu>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
CC:	"Serge E. Hallyn" <serue@...ibm.com>,
	containers@...ts.linux-foundation.org, jeremy@...p.org,
	arnd@...db.de, linux-kernel@...r.kernel.org
Subject: Re: [RFC v2][PATCH 4/9] Memory management - dump state

Dave, Serge:

I'm currently away so I must keep this short. I think we have so far
more discussion than an actual problem. I'm happy to coordinate with
every interested party to eventually see this work go into main stream.

My only concerns are twofold: first, to get more feedback I believe we
need to get the code a bit more usable; including FDs is an excellent
way to actually do that. That will add significant value to the patch.
I think it's important to demonstrate how shared resources and multiple
processes are handled. FDs demonstrate the former (with a fixed version
of the recent patchset - I will post soon). The latter will increase
the size of the patchset significantly, so perhaps can indeed wait for
now.

It should not be hard for me to add functionality on top of a more
basic patchset. The question is, what is "basic" ?  Anyway, I will be
back towards the end of the week. Let's try to discuss this over IRC
then (e.g. Friday afternoon ?).

Oren.

Dave Hansen wrote:
> On Wed, 2008-08-27 at 15:48 -0500, Serge E. Hallyn wrote:
>> Quoting Dave Hansen (dave@...ux.vnet.ibm.com):
>>> On Wed, 2008-08-27 at 15:34 -0500, Serge E. Hallyn wrote:
>>>> (Or, is that too much effort required on your part to try and
>>>> cherrypick bits of Oren's changes back into your tree?)
>>> That would probably work as long as Oren is working on top of what I
>>> have.  It's going to be a lot harder if I have to repeat the same
>>> break-out process for each iteration of Oren's patches, though.
>>>
>> If Oren's purpose is not quite to create a upstreamable patchset,
>> then it would make more sense for him to keep a git tree and
>> put new patches on top of his existing ones (within reaason as he
>> rebases).  Then you'd at least be able to trivially look at the latest
>> deltas.
> 
> The trick would be compromising on things that I, for instance, think
> need to be rewritten or removed.
> 
> Oren would have to rebase his work against what I do.  I guess you could
> think about it like me being upstream from Oren.  Anything that I would
> change, Oren would need to rebase on top of.
> 
> Oren, are you willing to keep a set of patches that add functionality on
> top of a minimal set that I'm keeping?  Mine being the set that we're
> trying to push into mainline as soon as possible.
> 
> -- Dave
> 
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
--
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/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives