[Devel] Re: [PATCH] c/r: Add UTS support (v4)

[Dan Smith]

I'm a little confused.  Haven't you already reviewed v4?  Perhaps you
meant to reply to v5?

OL> Need to test whether cr_hbuf_get() succeeds (while now it's
OL> trivial, in the future it may fail if we change the allocation
OL> method).

Hmm, that's rather unfortunate as it seems to make it messier.  I've
long wondered, why not have cr_write_obj() do the allocation (and
check) so that we can avoid the get and put in the caller?  I suppose
that introduces an additional copy, but it seems like it would make it
significantly more attractive.

OL> The 'h.parent' fields is gone.

Okay.  I need to re-base on your latest.  Sorry about that.

OL> If we plan to support multiple uts_ns, then it makes sense to save
OL> the 'objref' value. If you omit the 'objref' because you assume a
OL> single namespace for all for now, then you may also drop the loop
OL> on all tasks (below), for now.

<snip>

OL> I'm still unhappy with this loop. It isn't necessary now, since we
OL> assume and enforce a single, common namespace among all tasks. It
OL> is unlikely to be useful as is in the future because the format is
OL> likely to change anyway.  Even in the (userspace) restart part the
OL> code to read it is in the global section as opposed to per task
OL> section. Is there any reason to keep it ?

I guess I'm not sure why the format would change.  Rather, I would
expect it to look something quite like this when we do support nested
namespaces.  By having it there, it keeps mktree organized in a
similar way for when we do support it.

However, if you'd rather be very explicit about the unsupported-ness
of it, then I can just completely re-write it to reflect the naive
case.

-- 
Dan Smith
IBM Linux Technology Center
email: danms at us.ibm.com

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers