[Devel] Re: Linux-VServer and OpenVZ for Debian

[Kir Kolyshkin]

Adding devel@ into To: -- and I think we should move the discussion to 
devel. Ola, Igor, can you please subscribe to devel at openvz.org?

OK we agreed that vzctl should carry a private copy of needed kernel 
headers. Filed as bug #123, Igor should implement it soon.

Igor, what is needed from vzctl (summary):

1. Ability to choose arbitrary directories for different stuff before 
compilation (e.g. something like ./configure --vzconfigpath=/etc/vz 
--distscriptspath=/etc/vz/dists/; make) -- openvz bug #122

2. GPL license everywhere

3. Private copy of needed kernel headers -- openvz bug #123

4. setarch support ("personality" based on /sbin/init one) -- as 
discussed today

Hope I haven't missed anything.

PS note that dev@ should fix kernel headers to not depend on kernel's 
asm/timex.h (get rid off clocks_t type) -- it leads to inability to 
compile vzctl using 2.6.16 kernel headers which we have now.

Kir Kolyshkin wrote:
> Ola Lundqvist wrote:
> 
>>> The only problem could be the location of OpenVZ kernel headers -- it 
>>> is solved in different ways, say on our build environment we use 
>>> VZKERNEL_HEADERS env. var., while Gentoo ebuild uses some standard 
>>> ebuild library functions to locate the kernel sources/headers.
>>>   
>>
>>
>> I just downloaded it to get a feeling on how hard it is to make it 
>> work and
>> got this problem right away.
>>
>> My question now is if it is possible to have this header file inside the
>> source tarball for the userspace version. My question is actually what
>> I am building.
>>
>> * Am I building a kernel module?
>>  If that is the case then I would of course need this file.
>> * Am I building a user space tool?
>>  If so I really suggest that the header file is inside the source tree
>>  and that no external headerfile is needed (in the source tree). I think
>>  that is the way it is supposed to be, as userspace and kernel-space
>>  interfaces should not change anyway. It is not good to change that
>>  interface...
>>  
>>
> We do change those interfaces actually, because OpenVZ is evolving and 
> getting more features.
> 
> Still, yes, I understand your concerns, we will discuss it with Igor and 
> kernel guys tomorrow.