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

[Jan-Erik Soderholm]

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.spamnot 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.html in 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
>