Re: Bootstrapping Debian GNU/Linux distribution on SuperH
>>>>> In <20010922132716.A976@magi.sukisuki.org>
>>>>> "Oliver M . Bolzer" <oliver@gol.com> wrote:
>> > >>>>> In <200109210041.f8L0fFs09672@mule.m17n.org>
>> > >>>>> NIIBE Yutaka <gniibe@m17n.org> wrote:
>> I havn't even powered on my SH machines in some time due to travel and
>> exams, so I'm not really in a position to tell, but are 4 archs really
>> neccersary? How many people will use them ?
>> splitting the binary-sh in 4 incompatible arch seems to be too much
>> IMHO, not only for the porting and autobuilding (SH isn't very fast
>> as we know) but also for the FTP archives and the mirrors.
>> Because of this overhead we don't have an i586 tree, and that's good.
>>
>> An all SH3 environment will work on a SH4, but I imagine that's insufficient
>> for many people because they won't be able to develop native SH4 stuff.
>> Dropping SH3 is not an option, too.
I know discussion about binary-i586 tree, and I think it is different
the situation between binary-sh3 and binary-sh4.
i586 optimized binary and i386 binary is compatible. The user install
binary-i386 on Pentium class machine and some binaries (programs,
libraries) compiled with -mpentium or so (Pentium optimize). These
binaries can run on binary-i386 environment.
The user can mix i386 and i586 binaries.
But the user install binary-sh3 environment on SH4 machine, he can
not build SH4 binary on the environment (without some cross compiling
likes approach). SH4 binary can not run on SH3 binary environment.
The user can not mix sh4 and sh3 binaries.
This problem is described by NIIBE in another mail :
Message-Id: <200109220249.f8M2nmi13648@mule.m17n.org>
So, I think it is better that we have separate binaries
for SH3 and SH4.
>> How about the endianess? If I'm not wrong, the current tree is little endian.
>> Are really THAT many using SHx in big endian that it justifies having
>> another tree? Nothing against them but FOUR trees is just too much. I think
>> we should try to agree to a maximum of TWO trees, one for SH3, one for SH4.
Yes, current binary-sh is sh3 little endian binary.
Why currently we don't have binary-sheb?
Because nobody has worked for binary-sheb.
dpkg and some other tools support binary-sheb technically.
I agree that FOUR different architecture is too much.
I don't have SH3/4 bigendian machine, don't know SH3/4 big endian
machine.
And perhaps I can not manage all Four architectures same time ;-)
On the other hand, I agree that SH3/4 big endian support is
potentially needed.
So, I think that:
- Current target is Jornada 6xx series (SH3 little endian)
CAT68701 (SH3 little endian) and Sega Dreamcast (SH4 little
endian).
We need binary-sh3 and binary-sh4, I'll ask ftpmaster to create
these trees
- I do not have Big endian machines, I can not manage about these.
If anyone interest to provide and to manage binary-sh3eb and
binary-sh4eb, it is welcome. But currently we don't have any target
machine. Currenlty we do not need binary-sh3eb and binary-sh4eb
tree. So I will not ask ftpmaster to create these trees.
- Potentially sh3,sh4,sh3eb and sh4eb is needed. So, It is better
that if anyone write some source patches for SH3/4, these patches
includes all Four architectures supports.
>> Otherwise, the migration path seems reasonable.
Thanks.
--
ISHIKAWA Mutsumi
<ishikawa@linux.or.jp>, <ishikawa@debian.org>, <ishikawa@redhat.com>
Reply to: