Quoting Dwight Engen ([email protected]): > On Mon, 28 Apr 2014 17:54:46 +0000 > Serge Hallyn <[email protected]> wrote: > > > Quoting Dwight Engen ([email protected]): > > > This change accepts the same strings for lxc.arch that setarch(8) > > > does. > > > > > > When outputting the setting, use i386 instead of x86 since the > > > later is not a valid input to setarch, nor will the kernel output > > > UTS_MACHINE as x86. The kernel sets utsname.machine to i[3456]86, > > > which are all map to PER_LINUX32. > > > > > > Note that we continue to parse plain x86 as PER_LINUX32 so as not > > > to break existing lxc configuration files. > > > > > > Signed-off-by: Dwight Engen <[email protected]> > > > > Hi, > > > > the first part (expanding the list of allowed inputs) seems fine, but > > the second part seems like it could break existing callers. > > That's a good point. Using an older lxc version with a config that's > been cloned with a newer one won't work because the older one won't > parse i386. Maybe we should output i686 instead since older lxc's will > parse that. > > Or are you thinking it is too dangerous that there are callers outside > of lxc that would be confused by seeing i686 instead of x86? I can drop
Right, whiel it's highly unlikely, I could see some script parsing that output and being confused by new values. > the output part, it just seemed a bit wrong that we're using a value > that isn't valid from the kernel nor for setarch. Admittedly even templates seem to use i686 rather than x86. So perhaps outputting i686 is the best thing to do. -serge _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
