Subject: ARM Linux distributions

From: [email-masked]
Date: Thu, 8 May 1997 00:28:10 +0100 (BST)

Hi all.

The distribution that Phillip Blundel has recently been talking about
is an almost direct copy of what I, myself, am going to send him.  This
will be a totally untested distribution, quite possibly capable of
totally screwing your system.

For instance, the boot loader and so forth need to be tested on a known
problematic setup.  This known-problematic setup is basically a 1GB hard
drive from Acorn.  However, I do not currently have this drive.  It was
supposed to be with myself in January, but unfortunately, the Post Office
do not appear to be capable of delivering such a package - indeed it was
found last week up in Edinbourgh!

There does exist a known problem in the boot loader which means that it
*will not work* on large disks (disks > 512MB).  I believe that I have
fixed the problem, but am not positive, and indeed it may cause more
harm than good.

However, I have now received confirmation that it will be sent to me
to arrive later this week.  Once it has arrived, I can check out:

a) The RiscOS tools are capable of performing their function correctly.
b) The distribution has a hope of even installing.
c) The distribution has a hope of running.

Currently, it would be extremely foolish of me to do anything except
with hold ARM Linux until such a time that I can be reasonably happy that
there aren't going to be 100000000 people mailing me complaining about
the fact that this CD that they have paid for is only useful as a coffie
cup mat.

The distribution is currently moving as fast as it can at, since I have a
*full time*, no not 9-5, more 7.30am - 9pm job, 6/7 days a week, and that
simply does not leave time for ARM Linux to progress fast.  Unfortunately,
this style of working does appear to be all to common in Britian, especially
when impossible deadlines are imposed on saftely critial systems (eg. JLE PA
systems).

Dave Gilbert has the same sort of problem.  He maintains the Linux kernel
for the older machines, and quite honestly, it is only suitable for use
in a root NFS'd environment at the moment.  Floppy disk and MFM drives
are currently slow, and may not even work in the 2.0.30 kernel.  They
have even been known to wipe out his drives a couple of times.

Ok, so for those of you who have been saying 'the Web pages appear to
indicate that it is available':  They have not.  If anyone did read the
top of the page that details downloading (where there was a 'Read ME NOW'
section, which it appears to be customary to totally ignore, as are
README files on FTP sites), then people would have realised the reason
that certain directories on the FTP site were not accessable and not
available yet - in the README on the FTP site, I state quite clearly
(the whole README file is reproduced here for those who haven't read
it yet):

Directory of /pub/armlinux/distrib
----------------------------------

This is the initial upload of the new Linux installation / kernel system.
Please note that this is mostly ALPHA, and as such, may crash, do odd things,
or even screw up your hard disk.  You have been warned!

Note!  Certain directories may be locked against public access.  This is
intentional, since they're probably empty.

kernels                 Precompiled binary kernels
riscos                  RiscOS utilities for ARM Linux
tools                   Development tool patches for ARM Linux

So, the current situation is:

a) I have an arrangement with EESOX to produce ARM Linux CD ROMs.
b) I am currently extremely close to producing a CD ROM based installation.
c) I have access to a CD Writer at work to write 5 or so CDs.  These will
   be used to test the installation, and then I will approach EESOX to
   produce a silver CD ROM.

I am currently looking at around 1 weeks more work before finishing first
CD ROM image.  It will then take two days to move the CD ROM image to
work (via ZIP drive).  I then see 1.5 weeks testing, and then negotiation
with EESOX for CD ROMs.

This timescale will definitely change if I have to visit Coventry next week
to satisfy work commitments, since it may mean that I loose a couple of days
or more to install a PA system for system integration.

>From my web pages, I have around 305 replies to my CD ROM counter.  Lately,
it has been non-functional due to some reorganisation at cymru.net, the
nice people who are providing the CGI script to process your replies.  Since
I don't use the web counter, I rely on people letting me know if something
doesn't work.

As you can probably see from the date that this mail was sent and the times
mentioned above, I'm probably overworking considerably for this project,
and it would be such a shame to rush it, and risk loosing the project.

Basically, what I am trying to say is that ARM Linux is nearing release,
but it will have to come at its own speed.  If it takes 3 weeks, it will
take 3 weeks, no less.  It may even take more.  I cannot stress enough
that you must be patient.  If not, you could end up waisting a hell of a
lot of time - both yours and mine, and phone bills as well.

There is, however, one way to speed the release of ARM Linux up - employ me
to port it!

Thankyou.  I'm now going to get some sleep, get up, go to work, return home
at around 9pm, have dinner, and recommence work on the ARM Linux distribution
around 10pm tomorrow.

Please address any hate mail to /dev/null.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |       Russell King      [email-masked]         --- ---
  | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |      *  who wishes that he was in Hong Kong  *      ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Alan Cox <[email-masked]>
Date: Thu, 8 May 1997 09:40:26 +0100 (BST)

> totally screwing your system.

And ?

Remember SLS 1.0 ?

> the fact that this CD that they have paid for is only useful as a coffie

If it has all the bits on it, its useful for getting stuff fixed. 

> when impossible deadlines are imposed on saftely critial systems (eg. JLE PA

Fortunately in about 4 weeks you will be able to work 40 hours and tell
your employer thats enough, and they wont be able to fire you for it.

> have even been known to wipe out his drives a couple of times.

So long as people are warned this isnt a problem, the original sparclinux
trees came with big "Hazard" signs on them and people did eat disks, but
they found the bugs!

> lot of time - both yours and mine, and phone bills as well.

Personally I'd still rather have the "Doesn't work don't bug me bug
arm-linux" code tree up somewhere. Let Phil put the first one out as
a "Development snapshot" - cos believe me its far far more ready than
the mklinux HP-PA development snapshot 1 !

Alan

---

From: Philip Blundell <[email-masked]>
Date: Fri, 9 May 1997 12:29:56 +0100 (BST)

> The distribution that Phillip Blundel has recently been talking about

That's Philip, and Blundell.  Please do me the courtesy of spelling my
name right. 

> the fact that this CD that they have paid for is only useful as a coffie

That is simply not true.  Let's think about this a little more rationally,
shall we?  There is about 200MB on this CD, I gather.  Of that, the vast
majority is code that in all probability _will_ work fine.  Probably there
are bugs in the bootloader - probably there are bugs in the kernel as
well.  However, the reason people _want_ the CD is to avoid having to
download masses of precompiled binaries over slow links (even assuming the
binaries were available in the first place).  I'm sure they could cope
with downloading a replacement bootloader or a new kernel.  Perhaps some
of them can even fix the bugs themselves once they have a system that at
least works.

Nobody is pretending that this is a polished distribution.  By all means,
we should document the bugs.  But we should _not_ hold everything back
just because you're not sure it works properly. 

I think there are about seven people who have asked me to cut them a CD.
Even if they all mailed you I think you'd be able to cope. 

> There is, however, one way to speed the release of ARM Linux up - employ me

There is another way which you have been ignoring for the past four years.
If you were to actually release source code so that other people could
work on the project, rather than trying to do it all on your own, things
would move forward an awful lot faster.

While I have every sympathy for your being overworked, it is entirely
through your own volition that you work on ARM Linux, and positively
against other people's wishes that you try to be the only person doing so.
Frankly, this is (a) bad planning, (b) insulting to the rest of the
community and (c) starts to give rise to doubts about your motives.

p. (yes, I'm annoyed)

---

From: Philip Blundell <[email-masked]>
Date: Fri, 9 May 1997 13:09:31 +0100 (BST)

> with hold ARM Linux until such a time that I can be reasonably happy that

Incidentally, people who _have_ sent me cheques - don't worry, I haven't
cashed them yet, and obviously won't until I'm ready to actually send the
disks.  Sorry about the delay.  If anybody feels that in the light of what
Russell said they'd like to cancel their order for a disk, just let me
know.

p.

---

From: [email-masked]
Date: Sat, 10 May 1997 10:19:26 +0100 (BST)

> That's Philip, and Blundell.  Please do me the courtesy of spelling my

Oops! Sorry Phil.

> of them can even fix the bugs themselves once they have a system that at

I wouldn't say that the vast majority of bugs are in the bootloader/kernel.
They do appear to be extremely stable.  There are a few nigglies in there, of
course, but I'm not too concerned about them.  What I am concerned about is
giving away a totally untried and untested set of packages, which for all I
know would be a total failure and a waste of my money.

I have now received this hard disk from Acorn, and last night I did try
installing what I have done.  Lets just say that what it installed wouldn't
have worked at all.

> would move forward an awful lot faster.

I did not ignore this initially.  When I started this, I asked several
people, and put an announcement on the net, asking if anyone would like
to lend a hand with the project.  What reply did I get?  3 people from
Southampton, one of which attempted to port the kernel to his RPC600,
but couldn't carry on with it.

> community and (c) starts to give rise to doubts about your motives.

Ohh no.  If you think that then you've got the wrong end of the stick.  The
*last* thing that I want to do is to be the only person working on it.  I'd
like people to be working on it.  I learnt from my previous release for the
a5k that if you do put something up (and that took me 3 hours work on a
directly connected ethernet), there are still a hell of a lot of people
who will complain.

I've been putting up kernel patches for a long time, so that people can
work on it.  I've said that there is incomplete ARM600 nor ARM700 support
in there.  Do you think that I've received any requests from people wanting
to put it in?  One, and nothing came of it.  I haven't heard from him again.
So, is it me not allowing people to work on it?

>From what I've seen so far, people are all too keen to say 'Yes, I'd like to
work on such-and-such', but when it actually comes down to it, nothing
happens.  I've seen this too many times.

Ok Philip, you genuinely want to help, and have been wanting to help for a
long time.  You've sent me patches etc, which I have incorporated.  You
suggested the RedHat package manager, which I have followed.  I've speeded
up the console code, as you've asked for.  Every time you ask for something,
it stops me packaging up the binaries and source code to send out.

People *can* work on ARM Linux right now if they want.  All the patches for
gcc, the kernel, binutils have been on the FTP site for a long time now.
I know that the libc patches aren't there.  Even if they were, they wouldn't
be compilable under the 2.0 kernels, and that is known by the Linux community
at large.

What has become apparant is that people want a proper distribution.  They
want the binaries to be supplied to them, not patches.  They don't want to
apply patches.  The net result is where we are now - three people working
on ARM Linux.

It is not insulting to the community.  It is insulting to me that I have
supplied patches and such like, and then only two people pick up on them and
use them.  That's really insulting.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |       Russell King      [email-masked]         --- ---
  | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |      *  who wishes that he was in Hong Kong  *      ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Philip Blundell <[email-masked]>
Date: Sat, 10 May 1997 12:08:10 +0100 (BST)

> know would be a total failure and a waste of my money.

The packages have, on the whole, been tested by RedHat and thousands of
users across the world.  If they don't work properly on the ARM then the
most likely cause is a bug in some part of the ARM system, not in the
package.  In any case, I'm prepared to run the risk.  As Alan and I have
both said, it doesn't matter too much if there are bugs - in the worst
case, even if the CD _is_ only good as a coffee mat, people have only
spent a few pounds on it. 

> but couldn't carry on with it.

That's how it goes with these things I'm afraid.  When I started the hp300
port, I also posted to the net and got precisely no offers of help. 
Several people said "hey, that's a cool idea - let me know when you have
something that works, and I'll help then" but nobody wanted to help with
the gruesome business of hacking the low-level kernel code so that the
thing would boot. 

> So, is it me not allowing people to work on it?

You haven't made it that easy.  Kernel patches are all very well but
people need to be able to try out what they do.  If I hacked the kernel to
add ARM6 support today (and I don't imagine it would take long), what
would I do with it then?  I'd have a kernel image that I hoped would work,
but no way to boot it and no binaries to run under it even when it _was_
booted.  There is a certain body of code that people need, ideally in both
source and binary form (though just source would do) and that includes the
kernel, the C library and the bootloader.  Yes, you've released the kernel
but you haven't released anything else. 

> be compilable under the 2.0 kernels, and that is known by the Linux community

I'm sure we can work around that.  I very much doubt it's a big problem.
The Linux community at large isn't interested in libc4 any more, so we
can't really expect them to help. 

> apply patches.  The net result is where we are now - three people working

Yes, people in general want an easy life.  That doesn't mean they don't
want to help with writing the code (many people have mailed me saying they
do) - just that they don't want to have to go through a lot of pain and
suffering to do it.  Cross-compiling a kernel seems quite straightforward
to me, but then I've compiled thousands of kernels before.  Cross-building
an entire system to the point where it will boot and they can log in is at
best an awful lot of work, even if you know what you're doing and have the
hardware available, and at worst extremely difficult.

Now, when we spoke on the phone on Monday evening you told me that my
SyQuest was packed up and ready for you to post the following day.
Assuming that really was the case, and it has at least some version (even
if it's slightly old and buggy) of everything that people need, please do
what you said you would and post it to me.  Then I can cut the CDs,
everybody can install it and we're all happy.  Nobody who isn't on this
mailing list is getting a CD, so they'll all have seen the amount of grief
that has been involved in having them made, and I'm sure that if you don't
want to be sent bug reports they will respect that.

p.

---

From: Alan Cox <[email-masked]>
Date: Tue, 13 May 1997 09:55:34 +0100 (BST)

> can't really expect them to help. 

Well one thing you can do Phil if you are temporarily paused is to build
an a.out libc5. Ok we lose the dyanmic link -ldl stuff but I don't see why
a bit of GBH wont make the rest of it build a.out ;)

> want to be sent bug reports they will respect that.

An installable selfhosting system (however wobbly) is an important step
forward for people with only Arc machines.

---

From: Philip Blundell <[email-masked]>
Date: Tue, 13 May 1997 11:45:16 +0100 (BST)

> a bit of GBH wont make the rest of it build a.out ;)

I thought of that, but it didn't really seem worth it at the time.  I was
hoping that with only a bit more work I could build an a.out glibc, and we
could skip libc5 entirely for the ARM.  In terms of the glibc library code
I think about 90% of it is done now - we don't have the crt startup files
yet though.  Nor does it do .sa a.out-style shared libraries, and I'm not
totally sure whether that's worth putting in or not.

Is there any reason why libc5 is particularly desirable?  I was working on
the assumption that we just wanted something better than libc4.

p.

---

From: [email-masked]
Date: Wed, 14 May 1997 23:42:55 +0100 (BST)

> totally sure whether that's worth putting in or not.

If you don't use shared libraries, then the binaries do tend to turn out on the
large side (~100k each), and this is definitely not desirable, especially when
trying to build boot disks and the like.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |       Russell King      [email-masked]         --- ---
  | | | | http://whirligig.ecs.soton.ac.uk/~rmk92/home.html  /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |      *  who wishes that he was in Hong Kong  *      ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Philip Blundell <[email-masked]>
Date: Fri, 16 May 1997 10:54:21 +0100 (BST)

On Wed, 14 May 1997 [email-masked] wrote:

> If you don't use shared libraries, then the binaries do tend to turn out
> on the large side (~100k each), and this is definitely not desirable,

Nor is putting a.out shared library support into glibc, to be honest.  I
think people who want shared libraries can wait for ELF or use libc4.

p.