Re: architecture naming discussion

[Pjotr Kourzanov <peter.kourzanov@xs4all.nl>]

Alexander Shishckin wrote:

> On 4/27/06, Pjotr Kourzanov <peter.kourzanov@xs4all.nl> wrote:
>  
>
> > well, I am currently playing with these now:
> >
> > glibc: arm{,v4,v5te}-eabi, strongarm, xscale,
> > uclibc: arm-uclibc, i386-uclibc and mipsel-uclibc.
> >
> > and they are all linux, yes, but supposing that one day we will
> > want to look at uclinux or freebsd I see that the kernel must be
> > explicitly mentioned since then i386-uclibc (or uclibc-i386 for
> > that matter) might mean either linux, uclinux or *BSD. And in
> > that case, the $libc-$cpu order loses since $kernel-$cpu is already
> > claimed by hurd- and kfreebsd- architectures.
> >    
> I thought 3/4 of these kernels are pretty mouldy and/or starting to smell.
> But anyway, it would be great if finally someone ends up with a
> complete implementation of this idea. I'll be having hard times
> merging those with what I have now, but that's solely my problem.
>
> What this approach does not solve is this (mentioned a couple of mails
> ago): how do I fit ARMs and fpu-enabled ARMs in this scheme? Those are
> clearly two different architectures. And I can imagine a dozen of such
>  
FPU is a CPU-related thing, so it should be part of $cpu I think.
For ARM OABI this means having separate $cpu architectures
for: arm (hard-float), arm-softfloat (soft-float), arm-vfp (softfp),
arm-iwmmxt and whatnot.

> rather minor but pretty unpleasant things. I would trade any
> hurd/uclinux/openbsd stuff for a proper solution to this problem.
>  
Isn't ARM EABI a solution to this? The discussion on a proper name
for "arm-eabi" (which is my preference) is still ongoing, but it seems
that most likely armel/armeb will be chosen (where "e" is for EABI
and "l"/"b" is for little/big endian).

>  
>
> > With minor patches to dpkg{,-cross}, config.sub and debian/rules
> > this is all pretty much workable though...
> >    
> Undoubtedly.
>
>  
>
> > > Otherwise if it says uclibc-i386, your kernel is linux and libc is
> > >
> > >
> > >      
> > why? the kernel might be uclinux or freebsd.
> >    
> Ah, but you forgot that I take linux for the default kernel. :)
>  
I didn't forget about kfreebsd-i386-uclibc which in your case would
be kfreebsd-uclibc-i386.

> --
> I am free of all prejudices. I hate every one equally.
>
>