[Info-vax] Bare metal definition, was: Re: VMS port to x86

[John Wallace]

On Mar 27, 2:47 pm, Jan-Erik Soderholm <jan-erik.soderh... at telia.com>
wrote:
> Johnny Billquist wrote 2012-03-27 12:25:
>
>
>
> > On 2012-03-26 22:46, Jan-Erik Soderholm wrote:
> >> Simon Clubley wrote 2012-03-26 22:19:
> >>> On 2012-03-26, JF Mezei<jfmezei.spam... at vaxination.ca> wrote:
> >>>> John Wallace wrote:
>
> >>>>> Oh dear, not that silliness again. Not running Windows may be better
> >>>>> than running Windows, but running a Linux layer underneath the
> >>>>> emulator doesn't make it a "bare metal" emulator.
>
> >>>> Not sure how much of linux is included in that vtAlpha "bare bones". But
> >>>> it is quite possible to really have a bare metal linux and this is
> >>>> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>
> >>> In the embedded world, bare metal has a specific meaning. When your
> >>> application is directly addressing the hardware it's running on
> >>> without any operating system between the application and the hardware,
> >>> the application is running in bare metal mode.
>
> >>> When your application is talking to the hardware via a operating system
> >>> supplied API, that is not bare metal mode.
>
> >>> One specific example: one of the boards in front of me is a Atmel
> >>> SAM7S256
> >>> board (this one:http://olimex.com/dev/sam7-h256.htmlin case you are
> >>> interested.) When my application directly talks to the hardware registers
> >>> on this board and handles the interrupts directly, then it's running in
> >>> bare metal mode.
>
> >>> If I write a BSP for a RTOS and modify the same application to run on
> >>> this
> >>> board under that RTOS, then the application is no longer running in bare
> >>> metal mode.
>
> >>> If there's a cut down Linux between your application and the hardware,
> >>> then that application is not running in bare metal mode. :-)
>
> >> But Linux runs on "bare metal". And if that part is builtin in whatever
> >> the developer calles "the product", then what ? Doesn't "the product" then
> >> run on "bare metal"? Yes, one component of "the product" is some parts
> >> usualy called "Linux", but so what ? Why should the customer/user care ?
>
> >> The customer buys something called "vtAlpha" that can be runed on a
> >> new "bare metal" box without installing anything else before. Fine.
>
> >> In the same way, if someone buys your SAM7 "application" with a
> >> builtin runtime version of a RTOS, he could get a "bare metal"
> >> sam7-h256 board from Olimex and run it on.
>
> >> The term "bare metal" is more how the user/customer looks at it.
>
> >> If the user can install product "X" without pre-installing anything
> >> else, product "X" runs on "bare metal". Doesn't matter a bit (to the
> >> customer) what product "X" is built from.
>
> > That is a pretty meaningless definition. I could then just as well say that
> > my Firefox runs on bare metal.
>
> Yes, if you could get a packed version of Firefox that includes
> everything it needs to be installed on a "bare metal" box from
> the shelf. You can't. You need to have a system with an OS up
> and running to be able to install Firefox.
>
> If one would build a combined Firefox/Linux distribution (where
> Linux was more or less hidden from the user), then this would be
> a Firefox kit that installs and runs on a "bare metal" box directly.
>
> The rest below is "just" technical details that most users
> just couldn't care less about anyway.
>
> Jan-Erik.
>
>
>
> > It makes a big difference in that the underlying layer can and will hide
> > away and abstract away some parts of the underlying details.
> > That is the whole point of the underlying layer. Abstract away gritty
> > details of the hardware so that your software can be written in a more
> > general way and work on various different types of hardware.
> > But it comes at a costs. I no longer knows exactly what happens at the
> > hardware layer. That is handled by the middleware. As someone else
> > mentioned - what about hardware errors, as an example. I no longer get
> > reports of those, nor can my system perform actions to such errors. I'm
> > just presented with a preprocessed result to whatever request I made.
> > And if your expectations are that you are on the bare metal, then you
> > probably also expect all kind of potential hardware problems to be visible.
> > To *your* emulator, and not only to the underlying operating system...
>
> > Johnny

"a combined Firefox/Linux distribution (where Linux was more or less
hidden from the user), then this would be a Firefox kit that installs
and runs on a "bare metal" box directly."

Probably not that difficult to do with a LiveLinux CD and a bit of
ingenuity. And when you take out the CD, it's gone, nothing to see.

When someone finishes installing a "not really bare metal" HYPErvisor,
it leaves plenty of evidence behind. E.g. something bootable that can
be executed when the hardware powers up.

Moving on: VMS on native hardware is well characterised.

A Linux can have a variety of characteristics depending on the
particular Linux and the particular configuration. Some of these
characteristics (not just the realtime ones) will likely affect the
characteristics of a VMS system running in a "not really bare metal"
environment.

When you say "users" may not care about them, it depends on whether
you mean end users ie non-IT people sitting at VT emulators, or
whether users means the people installing (that word again) the
emulator, the people trying to continue to use VMS to run an important
business application, who may have little vendor support for
diagnosing problems when something occasionally goes wrong at low
level.