On Thu, Mar 04, 2010 at 03:22:16PM -0600, Adam Miller wrote:
>> > > RAM is a really good point, I think it will be in
the ballpark of 256
>> > > (plus or minus a bit). Also, I'd like to open up the conversation
>> > > about version of ARM we as a SIG want to support as the efforts start
>> > > to ramp up while targeting popular devices. I think ARMv9 might be a
>> > > little too aggressive but are there any devices that are still
>> > > prominent that are ARMv5? Would it be possible (or even feasible) to
>> > > maintain ARMv5, ARMv7, and ARMv9 in parallel and treat them as
>> > > separate architectures?
>> > The ARM "Family" vs. "Architecture" numbering is wonky
>> > frustrating - larger numbers don't reliably mean newer, bigger,
>> > or better). The SheevaPlug uses an "ARM9E" family chip, which
>> > "ARMv5TEJ" architecture. ARMv5 is a needed current target for
>> > device and others.
>> > However, the popular Cortex chips use ARMv6M and ARMx7* architecture. Is
>> > there enough performance difference to warrant targeting both
>> > independently? And just the kernel, or userspace as well?
>> I suspect building different optimised glibc andl openssl might be enough.
>> there could be some other packages that could benefit from different
>> optimisations things like theora etc.
> That's also my opinion.
This really might be my ignorance in the ARM world shining, but a big
point I would worry about would be power management support that I
assume would matter on the versions as they are SOC. But at the same
time I don't even know that has to do with the software. Anyone have
any insight into this?
Most of these are hardware and architecture independent features
exposed to userland by the kernel. I.e. the hardware specific details
of it all are handled entirely inside the kernel (in the ideal case,