[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

using Lilo for different kernel-images boot options.

Hello everyone,

Maybe a tool exists, or it's so simple, that I have missed it, but,
why does Lilo not 'sense' multiple boot images, and serve them
up as options, just like it does with different Operating systems?

That would  make it much easier to build/download, test and
auto-discover different kernels with only  a reboot cycle, in a 
semi-auto-managed tool? Integrating in a gui/web approach to 
kernel building and maintaining, including sources would be

Does this exist already?

The Laptop installation options on Linux now give multiple 
(ethernet) setup options during the boot sequence. Maybe a 
'matrix'  of kernels and ethernet options could be combined,
and managed via LILO, for both the environment (ethernet) and
the kernel image choices, during the boot sequence?

Where I really see this being nice, is for those persons with
multiple 'generic' and other forms of kernels testing
and maintaining a variety of processors in a singular or 
multiple microprocessor family, such as Arm, x86, ppc, etc.
Pushing the images and the builds via tftp(manually) or 
something like CFengine(automated) would afford hobbiest, with
limited chronological resources, the resources to collect
and deploy all sorts of embedded linux boards for experimentation,
hopefully with a wider community. The really sharp folks could
introduces hack(that could be readily compiled and tested) or
kernels (for newbies to download and test) in a very easy
fashion. Developers could have ready labs to test and veryfy
code, modules, kernels, security vulnerabilities etc etc.

This approach would also help those who aspire to know more 
about the internal kernel workings, to begin to learn how to
distinguish those sources (files and modules) that are essential,
versus those sources (files and modules) that creat enhancements
to the minimum kernel (RTOS) of a given embedded board.

It would also allow for statistical gathering of kernel performance
data, so the developers could distinguish between platform(environment)
issues, pure kernel-code issues, application issues and hybrid issues.

Any ideas on how to shape and influence such a scheme, are most
welcome. My guess is something already exist, that i'm 
unaware of.


Reply to: