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).
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
More information about the devel
mailing list