Quoting Brian K. White (br...@aljex.com): > On 5/14/2011 9:20 AM, Serge Hallyn wrote: > > Quoting David Serrano (dserra...@gmail.com): > >> On Sat, May 14, 2011 at 00:15, Serge Hallyn<serge.hal...@canonical.com> > >> wrote: > >>> > >>> I'm curious, whatcha got in mind? > >> > >> I don't think you have to have something in mind to implement this. > >> Just that old motto "Be lenient in what you accept" :). > > > > So if I type 'lcx.' instead of 'lxc.', as I often do, it'll silently > > ignore it? No, that's a bad idea. > > > > In any case I wasn't (until now) doubting Daniel's motivations, rather > > I was pretty sure he had something neat in mind. > > I like it but I can't think of anything off hand that I'd use it for > that I couldn't just as easily use either comments or a separate file to > do. And obviously as you point out there's an argument for enforcing > only known options as a basic sanity check. > > On the other hand there have been plenty of times where I wished > something would gracefully ignore options it didn't recognize which came > from newer versions or from distribution patched versions. It gets in
Note that this patch won't make a difference for unrecognized, newer lxc.* options anyway :) It would however allow for interspersed 'libvirt.*' options, for instance, to support inline hints for a new libvirt-lxc2 driver. Probably not what Daniel is looking to, but not impossible :) -serge ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users