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

[Johnny Billquist]

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.

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

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol