Re: Out of tree kernel images / Lustre image
Dropping security as this is only kernel related now.
Bastian Blank <email@example.com> writes:
> On Tue, Aug 01, 2006 at 05:59:43PM +0200, Goswin von Brederlow wrote:
>> Now to my question. Lustre needs a specialy patched kernel
> Why? Ah I see, they don't know how to abstract that and get informations
> how to do that properly from upstream.
>> and builds
>> a ton (~100MB uncompressed) of kernel modules and support
>> binaries. How should that be handled?
> Modules needs to be seperated from binaries.
Obviously. There is also a library so there might be even more debs in
>> Would it be OK for lustre to build its own out-of-tree kernel image
>> and modules?
> It is the same than fai-kernels which is scheduled for removal.
What you mean is 'NO'?
>> Or would that be too much extra work for the security
>> team to support?
> If you want to be correct, you can't use linux-source. So the security
> team have to support another kernel source.
Why can't I build-depends on the linux-source tree? Is there a writeup
of the reasons fro FAI already that I should read?
>> What is the policy on this kind of thing?
> As the kernel team to provide them. But with this flacky patchset, this
> won't work.
Who says it is flacky? What is flacky? Like a flack? :)
The patch set is quite intrusive to the kernel. Some core VFS
functionality is touched that you might not want in normal kernels so
it will always have to be optional for the lustrefs flavour.
The other thing is that so far every upstream release (2.6.15, 2.6.16,
2.6.17, 2.6.18) has caused conflicts with the patches because the VFS
and ext3 code gets changed around a lot recently. I'm not sure I have
the time to adopt the patches all the time in time for those 0 day
releases on kernel updates. That probably makes it unacceptable for
the main linux-source package.
PS: How is xen doing this? Isn't that quite intrusive too?