Hello kernel-discuss,
After more discussion on IRC, we decided to go
*_static_defconfig way. By now I've committed
h3900_static_defconfig
h4000_static_defconfig
hx4700_static_defconfig,
and updated http://handhelds.org/~pfalcon/busyb/buildlogs/ to use
them. Corresponding *_defconfig are now deprecated (and nor maintained
for some, or long, time). They are kept for reference, to migrate all
features to defconfigman-generated ones.
I also found regression with h4000 DiskOnChip support. As this is
firefighting unless we have proper infrastructure to have
formal/automated means to check for such regressions, I've added
bootlogs for each of the above defconfigs to CVS. In ideal situation,
each defconfig update would be accompanied with bootlog update, and
such way, it will be possible to tell clearly what changed when.
Testing of new defconfigs is welcome!
Friday, March 30, 2007, 1:20:25 PM, you wrote:
Hello pHilipp,
Friday, March 30, 2007, 11:51:00 AM, you wrote:
On 3/29/07, Paul Sokolovsky [EMAIL PROTECTED] wrote:
Hello kernel-discuss,
So, now that defconfigman functionality was tested/tweaked by few
developers, I'd like to proceed with discussion what featuresets we'd
like specifically for the default CVS defconfigs. Actually, uncertainty
that we have unanimity here caused me to not commit defconfig even for
h4000.
So, let me express how I feel about it. I'd imagine these
default configs to serve as many purposes as possible. This would mean
that they should package as much features as possible, and yet be easy
to use. For example, usage I can envision are:
1. Track newly added/refactored features closely, so were useful for
both manual and automated tested.
2. Be such that maintainers actually use for testing.
3. Be such that maintainers are confident to recommend users to start
with on their way to hacking.
4. Be easy for novices to boot.
5. Be easy for folks running production systems to boot.
6. To be suitable for acquaintance and examination of kernel features.
...
IMHO, to (try to) satisfy above criteria, kernel should be:
1. Static - I guess, noone will dispute the fact that it's really easy
to have static kernel booted, at leaves big freedom trying different
rootfs without bothering with modules install. It will also folks who
run production system to easily test a new kernel too, without fear to
contaminate their system or go thru long preparation.
As I said before, I am of the opinion that distro kernels should be as
modular as (sanely) possible.
I fully agree. Moreover, as I told, I see all this consistent defconfigs
stuff as an evolutional step towards common kernel, where all
machine-dependent stuff will be as much in modules as possible.
But that's why distros maintain own defconigs, and build using them.
For the current discussion, I'd like to settle question of what we'd
like to see in defconfigs we keep in our kernel CVS, and as distros
have own copies anyway, we may have own scope for them (and should,
IMHO).
Otherwise module / module dependency
handling will bitrot because nobody looks at it anymore.
To solve the kernel / module problem I'd like to see some initramfs
infrastructure that makes it easy to provide the correct modules with
the kernel and some way to put the kernel itself inside the rootfs
under package management control like the modules where possible
(which would make the system more desktop-like) with simple jffs2/ext2
support in the bootloader.
Sure, these are all nice points and ideas, I'll be glad to continue
discussing them in the scope of OE/Familiar. But now what's important
to point is that distro indeed offers entire infrastructure for
seamless maintenance of modular kernel config within bounds of
system-wide package management.
But kernel tree itself does not. So, with distro, to upgrade
module(s), you need do just do ipkg install kernel/module name.
With barebone-built kernel, you need to either:
1. Transfer modules manually to your production system and pray you're
careful enough to not have done stupid mistake (think newbies)
2. Mount your initrd image and copy it them
3. Uncompress your initramfs and copy it there, then recompress and
pray you didn't mess links/permissions.
And I strongly believe that need to do steps above poses pretty steep
barrier on the road to involvement of more people into kernel
hacking/testing. And IMHO, we shouldn't create artificial barriers
like modules are important, so you must bite at them from the very
beginning if you want to be a kernel hacker.
Again, all above applies to our kernel project. Distro projects have
other aims and other infrastructure to achieve them. In this respect,
defconfigman of course allows to create defconfigs for both (multiple)
from the same set of machine definitions. Of course, that means that
machine maintainers would need to deal with 2 defconfigs - well, my
idea
