ISO/Core additions

[Auke Kok]

Moritz Heiber wrote:

>Hey Auke,
>
>1) I think we should include udev by default on the ISO. The 2.6.x
>based kernels need it for node transactions now as devfs is NOT
>supported anymore (as of 2.6.13.x). Without having udev installed any
>update from 2.4.x to 2.6.x will fail!
>The mount script holds some good logic to take the right choice for
>device node handling. We just need to supply udev.
>  
>

not for any 2.4 iso, once you are done installing there is nothing that 
keeps you from downloading and installing udev yourself - period.

after 1.5.2 I'm gonna have a go at making a 2.6 iso - lets not get 
stupid and duplicate work here when it's not needed.

>2) We need a function in the core to determine the currently running
>kernel.
>

uname -r

> We could modify the mount script so that once it mounts the
>root filesystem it writes some sort of value or file to the system
>(even into / .. maybe as a hidden file; If you can think of anything
>smarter to determine the booting kernel then SAY IT!) which then is
>picked up by the coretools. That would help A LOT with modules that are
>2.4.x (like alsa-driver) or 2.6.x (like madwifi-cvs, ipw2100) only
>(like spitting out warnings or refusing to install a certain module) ..
>and help with the next point ..
>  
>

you don't want to compile modules against the currently running kernel, 
you want to compile kernel modules against the last-installed-kernel 
(which was installed by a `lin linux-2.*`), as this is the only kernel 
that needs new modules to be compiled. You also want to do this before 
rebooting as these modules might be vital to getting your box booted and 
networked.

So, most preferably, we want to compile modules for 
LAST_COMPILED_KERNEL, which should be saved by the coretools/modules at 
the end of a succesfull BUILD (`set_local_config LAST_COMPILED_KERNEL 
$(grep UTS_RELEASE include/linux/version.h | cut -d '"' -f2)`).

All lunar modules that compile kernel modules need to refer to 
`/lib/modules/${LAST_COMPILED_KERNEL}/build/include` for the proper 
kernel headers - some already do this but most need a 
--with-kernel-headers flag.

Using /usr/src/linux/include to compile against is wrong per definition.

>3) Have modules-2.4 and modules-2.6 instead of one single file. Because
>module lists for these different kernel architectures are not likely to
>be the exact same.
>

stop doing the work of the user, let them do it themselves or install 
discover - that does a marvellous job for most base modules anyway. lnet 
also allows you to list a networking module too - when exactly have you 
ever needed something like this?

> Also, we should have the user edit those files on
>every kernel compile (like we do it with the lilo/grub thingy now ..
>including a question).
>

absolutely not. that's just silly. I would have to implement a 
DONT_ASK_ME_SILLY_QUESTIONS flag to counter it.

> We should also have those files updated
>automaticly with the modules that were just compiled to help the user
>keep track of the kernel-modules he has (of course they'd be blanked
>out by default to not mess with his configuration and duplicates need
>to be detected).
>
>4) We should have kernel-reqs-2.4 and kernel-reqs 2.6. That is the
>easiest part of it all. Madwifi-cvs can be installed .. but it must not
>be relined once we install a 2.4.x based kernel.
>  
>

that's fine with me, make sure kernel-reqs-2.4 doesn't conflict with 2-6 
incase people want to keep them side-by-side.

>These problems must be addressed .. I think I can even do point 3 ..
>its merely making a copy of the already present lilo handling function.
>Help and suggestions appreciated!
>  
>

Item 3 is the least usefull of them all, I'd prefer to see #2 
implemented which is really the most important one of them all.

>Tell me what you think!
>
>Moritz
>  
>