On Sat, Jun 02, 2007 at 05:29:55AM +0200, Lennert Buytenhek wrote: Hi Lennert, > I'm posting here because I would really really like to get the relevant > diffs merged back into Fedora. I took a quick look at the kernel dir, and the specfile changes are pretty unoffensive, and mergable imo. The config file however I think might be better served if it was done differently. Instead of having a single flat config file, the Fedora kernel rpm generates configs out of templates (see configs/ dir in cvs) It should be fairly simple to change this though.. just remove all the symbols from your current config that are already in config-generic (except for ones you want to override). Then add a stanza to Makefile.config to call merge.pl on config-generic and config-arm. The advantages of doing it this way are that we don't have to update n config files when upstream adds a new option, just adding it to config-generic gets it automatically added to all archs where it makes sense. Having a quick scan through some of the options you have set.. # CONFIG_UTRACE is not set note that this will also disable ptrace too afaik. (I'm aware that there are difficulties of porting utrace to arm). CONFIG_DEFAULT_DEADLINE=y Any reason not to go with CFQ like we do on other archs? CONFIG_IDE=y Has anyone looked at porting the ARM ATA drivers over to libata ? # CONFIG_VT is not set Is this always going to be useless on ARM ? # CONFIG_MMC is not set might be handy for handhelds ? # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT3_FS_XATTR is not set # CONFIG_SECURITY is not set aww, no selinux ? There's a lot of stuff built in =y, rather than modular which seems a little wasteful. (In fact, there's nothing =m, yet CONFIG_MODULES=y :-) There's a few things that stuck out that seem like they may be useful (ipsec support for eg) in some use-cases for embedded systems that were disabled. I'll concede that Fedora-ARM is breaking new ground here, in that its the first arch we're supporting (other than olpc I guess) where the size of the generated rpms is a concern, but I think there's probably a balance to be struck between what we have so far, and a 'generic' kernel that may be of use to many different projects without them needing to rebuild parts of the kernel that were left out. Dave -- http://www.codemonkey.org.uk -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
