Re: Bug#67888: marked as done ([CVS-fixed] Netwinder/arm port shouldn't ask about maintaining 2.0 compatability)
On Thu 23 Nov, Adam Di Carlo wrote:
> Wookey <wookey@aleph1.co.uk> writes:
> > On Tue 21 Nov, Debian Bug Tracking System wrote:
> > > >From andersen@codepoet.org Sat Jul 29 01:11:08 2000
> > > Return-path: <andersen@codepoet.org>
> > > The debian installer for potato worked just fine on the netwinder, one
> > > I convinced it to tftp boot the provided netwinder-rescue image. One
> > > hitch though -- the question about maintaining 2.0 compatability for
> > > the ext2 fs should be removed and forced to "yes". Answering "no"
> > > causes the netwinder's firmware (which is just a stripped down linux
> > > kernel) to be unable to read the filesystem -- so it is unable to boot
> > > the system. Not that big a deal though.
> Could you file this as a bug?
erm, are you confused adam? The above para has already been filed as a bug
and you replied saying it was fixed in bf2.2.17 (see below - it was this
message that I replied to). That's all fine so far as I can tell. Or do you
mean I should file the fact that this causes (may cause?) a different problem
for RiscPC as a bug?
> > > >From adam@onshore.com Tue Nov 21 05:21:28 2000
> > > This bug was fixed in one of the last two versions of the
> > > boot-floppies, either 2.2.17 or 2.2.18, both of which are in Potato
> > > now.
> > Erm, this is all fine for netwinders, but for a riscpc (the other main
> > arm desktop platform) this option does not need to be forced to yes. This
> > is just one of many things that vary between arm platforms (which are
> > fairly hetrogenous). I don't know what the disadvantage is, but if it
> > affects disk speed then as the riscps is 'very slow' in this dept it
> > would be nice to have the choice.
> > There are several things that need to be done differently for different
> > arm sub-platforms. Is there an approved mechanism for this at the moment
> > or not?
> You'd have to ask the ARM porters. Other arches with subarches (such as
> sparc) look in /proc/cpuinfo and such and automatically deal with this.
I _am_ the ARM porters :-). Well, it's not quite that bad, but I'm one of a
very few people working on bf for ARM. I take your point that it is better to
check this at runtime if possible and take appropriate action than to make
different boot-floppies sets, where possible. I was just wondering whether
there was official bf policy on how to deal with subarches so that things
remained consistent. I'll check out the code and get it to use /proc/cpuinfo
if appropriate.
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679
work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Reply to: