[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problem installing Slink on UDB/Multia

On Friday, 14 May, Nathan P. Hawkins III wrote:
> I guess I'm not really thrilled with MILO or ARC, and SRM seems to be the
> best of the lot. ARC is horrible. MILO seems excessively stripped down.
> - From what I have seen in the PALcode docs, I'm inclined to say that it can
> and probably should be able to do a lot more than MILO does.

True, but nobody in the Linux world uses those features anyway.  Speaking
of PALcode, MILO only lacks four calls (gentrap, urti, wrperfmon, wtint)
and interrupt vector calculation.  Most of the difference between SRM
and MILO is outside the PALcode - callback service routines, environment
variables handling.  It would be great to bring MILO's PALcode to the
SRM level, but the rest is mostly useless.  One service routine should
be enough - the one that prints messages to the terminal, for early
kernel diagnostics.

After all, the console is there only to boot an OS...

> Good point. But I'm trading a little memory for being a lot more confident
> that it will boot up without help. ARC+MILO kept getting stuck. I had a
> UDB at a remote location that rebooted itself every once in a while.
> (Hardware problem.) Then, the firmware would just sit there, until I drove
> down there and manually straightened it out. Ram is cheap. Outages aren't. 


> If someone were actively developing MILO, most of these things could be
> addressed by now, don't you think? I haven't seen any sign that anyone has
> done anything with it for quite a while. Not if it's home is still on
> gatekeeper. 

There is a better maintained branch (ftp://genie.ucd.ie/pub/alpha/milo).

What I really like about SRM is that it's supplied by hardware vendors.
Console, especially PALcode, is part of hardware.  Nobody else can write
it better.  MILO is much more generic than SRM is, at the expense of
performance and stability.  To maintain MILO accurately, two things are
required: full hardware documentation and the equipment to play with.
(Apart from free time.)  People at COMPAQ are busy with other things;
other developers seldom have the prerequisites mentioned.


Reply to: