fedora for ARM

[Dave Jones]

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