Re: Problem installing Slink on UDB/Multia
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 14 May 1999, Nikita Schmidt wrote:
> On Thursday, 13 May, Nathan P. Hawkins III wrote:
> >
> > On Fri, 14 May 1999, Martin Lucina wrote:
> > > Also note that SRM/aboot IIRC will eat a lot (4.5mb?) of memory.
> >
> > Maybe some clever person with time on their hands will do something about
> > that. Seems to me that something more like SRM would be nice. For that
> > matter, what's wrong with actually using SRM itself?
> >
>
> Itself - you mean, instead of SRM/aboot? There is no difference. Aboot
> is just a tiny layer which does not take up any resources once the control
> is passed to the kernel.
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.
> To summarise briefly:
>
> * SRM is not available on all platforms, neither is MILO.
Nor ARC.
> * SRM eats much more memory than MILO. On my machine, it's about 1.5 Mb
> for SRM and slightly less than 0.5 Mb for MILO. This is probably
> irrelevant on these modern 256 Mb machines, but still makes me a bit
> unhappy about the wasted memory. Just think about it: you run Linux
> for months non-stop, and what does it preserve so carefully all this
> time in a far corner of its high-tech semiconductor memory? OpenVMS
> PALcode!
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.
> * SRM's PALcode is generally better than the MILO's one, although in
> most cases this is not noticeable. Three notable differences are:
> - interrupt processing: MILO does not pass the interrupt vector to
> the kernel, making kernel do more work;
> - missing wrperfmon call in MILO prevents from using performance
> measurement tools such as Iprobe;
> - missing wtint call in MILO does not let Linux enter low-power CPU
> mode in the idle loop.
> SRM can also play highly platform-specific tricks in its PALcode.
>
> * When booted from SRM, the kernel has to worry about saving/restoring
> some parts of machine state.
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.
---Nathan
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
iQDVAwUBNzxVTaUqhOQsTZ+hAQF9PwX+JNmvGCDcWE2A6ZMhzk1ax+uOz9GkQ440
PF+7bZV0NlbyYUW0uotOVFUR12rC+14lUDWfmuuIS6JPb3aAd3RUKAHICYCRoEnF
chDF6SPa3QE07SXl3LeLd9L5mqLdd/4YYKjsj8v3D7hp+VNBHDO+wKXxLN8FWpGX
AZKTVn6b/KJzoY6fcsYJZ57/7XxV8F/gQI5BNzKKrNOPH25GuxZgotVg9s+NEbTm
Xh/NRA0Mn2gzpQw81ZZgjiLHoLcdFE4J
=5N3L
-----END PGP SIGNATURE-----
Reply to: