fedora for ARM

Dave Jones davej at redhat.com
Sat Jun 2 18:38:28 UTC 2007

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).


Any reason not to go with CFQ like we do on other archs?

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,

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.



More information about the fedora-devel-list mailing list