> I've been playing around with MILO the last day or so to get my mind
> off the Interrupt problem that I've been having...
Welcome to the true kernel headaches :-)
> I've noticed there is a lot of fluff in milo now. Lots of commands
> for dumping registers, etc. These are wonderfully useful (in fact, I
> want to add to them, see below). However, they have grown to about
> 14k out of 50k. If they were eliminated, that would make MILO load
> about 30% faster than it does now. On my machine with its disk drive,
> this could be a win, so it is likely a win for others. I'm thinking
> of hacking milo in the following way:
I'm also not very lucky with the implementation of these commands. After
building Pandora is a symlink to Milo; definately not the real thing ...
> By default, milo will be as small as we can make it. There will be
> options that you can turn on, however, that will bloat milo so that
> it can be more useful. The defaults don't matter to me, so we can
> turn this around. However, I'd also like to add "ls" and "cp" to
> milo, plus the ability to do decompression and grok ext2fs file
> systems. The reason for this is so that we can repair disks from MILO
> and not need to build a new kernel. At least that's the theory, it
> may turn out to be too much of a PITA to do all of this, but I do want
> to do the decompression and cp and ls at least for FS that support
> this (eg FAT and ISO-9660 and maybe TFTP for cp). The decompression
> is for kernels and for fonts for the console, etc.
> Why do I want to do this?
> Well, I discovered this weekend that this really old disk that I've
> had laying around is actually not useless. The UltraStor 34F
> controller in my PC wouldn't recognize it at all. Since I'm looking
> for a disk for the Deskstation (the one that I had borrowed from it
> bought the farm recently), I thought "Heck, there is no way this will
> work, but I'll give it a shot none the less." And it worked. Now I
> want to put MILO on the hard disk. I could just hook it up to another
> machine and do a copy. However, I thoguht to myself, "hmm, people are
> going to need to do this for their machines" so I thought "Hmmm, this
> would make a nice side trip while I ponder the state of the interrupts
> on my machine." Maybe not the best reason do to something...
> However, after the fact I realized we'll have to be able to do things
> like this under ARC BIOS for the install anyway, so I thought now
> might not be a bad time to look into the difficulty of providing cp
> and maybe ls for MILO.
> Actually, MILO is a good core, but we'd need something like SASH that
> was on Solbourne machines (and maybe Suns). If we did this right,
> then we could layer the bootstrapping part of the OS on top of SASH.
> Something that would potentially partition the disks, format the
> partitions, copy milo, vmlinux, et al onto the machine and rebooting
> into the real install process like NT does.
You're right; I've tried some days ago whether Arc drives may be accessed
similar to UNIX block devices - et voila - it works though not documented.
So partitioning under ARC can really work (withhin the narrow limits set
by some extremly buggy ARC implementations like the Magnum ...)
What is missing is a port of termcap to Arc; then we could use programs
like cfdisk for installation. Another program that might be interesting
to be ported to Arc is an sash type shell with lots of builtin programs
that recently has been published. Think it's name was mash.
The sad fact that every Arc BIOS I've yet seen will turn writing a complex
Arc program into a walk through a minefield. Even worse; Arc is bugged by
design. There are all functions required to access and manipulate files -
except a function to delete files. Btw. - the mines are (C) Microsoft ...