trickie at gmail
Jul 26, 2008, 12:44 PM
Post #11 of 14
Re: Community Kernels garage project created
[In reply to]
On Tue, Jul 15, 2008 at 10:50 PM, Jason Edgecombe
<jason [at] rampaginggeek> wrote:
> Marcio Macedo wrote:
>> On Tue, Jul 15, 2008 at 12:20 PM, Jason Edgecombe
>> <jason [at] rampaginggeek> wrote:
>>> Graham Cobb wrote:
>>>> On Tuesday 15 July 2008 09:25:36 Frantisek Dufka wrote:
>>>>> Primary goal is to accumulate kernel patches so they do not get lost,
>>>>> secondary goal is to build kernel images for all devices and latest
>>>>> versions of all IT200x releases. Patches should primarily apply to
>>>>> kernel sources release in Maemo SDK (i.e not current linux-omap).
I like qwerty12's idea of keeping patches in a quilt set, I replied in
the garage forum.
I think until the autobuilder/extras-devel process is defined, we
should be collecting patches already floating around and maybe keeping
a table of the status of those patches (stable(ish), experimental,
developers only, only for version 2.6.21-omap-blah etc etc).
If we have those patches as a quilt set, then someone can already grab
the maemo kernel sources and get our quilt set from svn and push the
patches they are interested in.
Once the build process is defined we can choose which patches have a
status worthy of going in the extras-devel build. Then we can start
making 'spins' with different patch sets if that makes sense.
I don't mind collecting patches for now, so if you have some code
floating around or a known location of something interesting to the
project, reply here with it and i can bundle them up (and make a quilt
set ?) ready to go in svn
>>>> Do you see this also addressing the related issue of building and distributing
>>>> kernel modules?
>>>> I have a package (sisusbvga) which contains a kernel module (to drive an
>>>> external VGA adapter). At the moment, I have built the kernel module using
>>>> the instructions on the wiki and then I package it up as a binary blob -- in
>>>> other words the debian package does NOT build the module from source. If
>>>> possible, I would like to change that so that the debian package builds the
>>>> module, in the autobuilder.
>>>> Actually in my case the situation may be reasonably straightforward: the
>>>> sisusbvga driver is actually part of the standard Linux kernel, although a
>>>> patch is required to get it to build for the Internet Tablet (I ought to
>>>> submit the patch to LKML one day). So, I guess it falls within the scope of
>>>> this project anyway, assuming you are addressing the problem of kernel
>>>> modules as well as the kernel image itself.
>>>> There are another couple of issues -- are they part of this project?
>>>> Firstly, as it stands today, I can't find a way to install the module such
>>>> that it can be found and loaded automatically when the hardware is seen on
>>>> boot: /lib/modules is only in the initfs.
>>>> The other problem is how to deal with kernel versions. I believe the plan for
>>>> Maemo going forward is that even kernel upgrades may occur. What package do
>>>> I specify as a dependency so that my package only installs on the correct
>>>> kernel version? How do I get the autobuilder to build the various versions
>>>> of my module needed for the different kernel versions? What magic do I need
>>>> to put in my debian/control to get the installer to install the correct
>>>> version of my module for the kernel version?
>>> I have a similar issue where I have to maintain the openafs kernel
>>> modules, but I am trying to get them to automatically build in the
>>> autobuilder. my module lives in a odd folder and is loaded by the init.d
>>> script so loading is taken care of. I will continue to maint the openafs
>>> kernel module along with the openafs package.
>> The fuse module, from the package fuse-modules-rx-34 is installed at
>> and it is loaded by the default kernel.
>> I didn't find a good solution for building kernel modules in
>> autobuilder, except building the whole kernel first.
>> I don't have much experience with kernel modules, but maybe there's a
>> way of avoiding compiling the kernel every time I want to build a
>> single module.
>> Maybe someone with more experience building modules can give some hints.
> I thought that too, but I seem to be able to get away with running the
> following in the kernel source to make things work "make distclean; make
> n800_defconfig; make modules_prepare"
> I'm having trouble with fakeroot and scratchbox building my package but
> if I get to the autobuilder, I'll let you know how this works. There is
> a kernel-diablo-headers package but it was not enough to compile kernel
> modules against.
> maemo-developers mailing list
> maemo-developers [at] maemo
maemo-developers mailing list
maemo-developers [at] maemo