Re: Rd: [RFC] dl-procinfo and HWCAP_IMPORTANT support for powerpc

[Benjamin Herrenschmidt <benh at kernel dot crashing dot org>]

On Mon, 2005-12-26 at 10:09 -0600, Steve Munroe wrote:

> I am NOT ignoring embedded. The dl-procinfo mechanism is just part of a
> comprehensive proposal which starts will the --with-cpu= support. This
> (--with-cpu=) mechanism can support an arbitrary number of <cpu_type>
> implementations.
> 
> The dl-procinfo mechanism supports a specific delivery model (fat rpms with
> multiple implementations of libraries). This mechanism is about "delivery
> to the customer" associated with general purpose distro's. So the Apple G3,
> G4's ... should be added to the dl-procinfo mechanism.

 .../...

Heh, there is no need to bring up the buzzwords ! :)

I know what you want and I agree, I was just trying to point a specific
technical detail of the implementation, which I think might corner us in
the future if we aren't careful.

> However it is my understanding that embedded processors don't (can't) use
> the general purpose distro's. A embedded Linux SDK can be very specific to
> the chip and doesn't need the fat rpm mechanism. So IMHO the dl-procinfo
> mechanism would never be used in practice for the embedded space (they will
> build the single libc.so they need and ship that with the SDK).

It depends. Been there done that. You can have a line of products using
different ppc embedded processors and wanting to have your core userland
identical for maintainance/upgrade reasons. In fact, "embedded" covers
pretty much any situation which is why I'm keen on making sure our
solution is scalable enough.

> So the key to resolving this issue is to understand how the embedded folks
> deliver the SDK to their customers. If I am misinformed, then some one who
> actually works on Linux for the embedded space, should speak up.

They all do differently. Anyway, there is no need to focus on embedded
now, it's just one piece of the puzzle.

> Fine. I asked for the AT_HWCAP bits because it was implemented, AT_PLATFORM
> was not. It was just easier to extend an existing mechanism then define a
> new one.

Euh...yes, but AT_HWCAP was implemented for feature bits. We just only
added some microarchitectures to it, afaik, upon your request. It's all
new enough that I don't see the problem in discussing it and possibly
coming with a better alternative.

>  Also in the current dl-procinfo mechanism, AT_HWCAP allows for
> multiple modifiers (like ALTIVEC combined with POWER4 or G4). AT_PLATFORM
> does not. This allows for "commoning up" based on ISA features independent
> of microarch.

Yes, but that isn't incompatible. For example, a 970 could/would be a
POWER4 microarch with the altivec feature bit set. In general, features
like altivec _has_ to be independant bits anyway since LPAR environments
might make them unavailable even if the processor we are running on at a
given point in time supports them.

Ben.