Difference Between "Machine Hardware" and "Hardware Platform"

Difference between machine hardware and hardware platform

In your case what it tells you is, you're running a 32-bit operating system on a 64-bit processor. Code is compatible with a 386.

They are:

• the machine hardware name (sometimes called the hardware class or hardware type).
• the hardware platform name (sometimes called the hardware implementation)

The first one says something about the CPU that was detected. The second one about target architecture the uname program was compiled to. On some CPU's they default to 'unknown'. The kernel should provide this information, but if there is nothing available it defaults to hard coded strings.

In my case:

$ uname -a

Linux godiva 2.6.30-amd64 #1 SMP Tue Oct 27 09:12:19 UTC 2009 x86_64 GNU/Linux

$ uname --machine

x86_64

$ uname --hardware-platform

unknown

what's the difference between `uname -a` and `uname -m`

From man uname:

   -a, --all
          print all information [...]

   -m, --machine
          print the machine hardware name

   -p, --processor
          print the processor type or "unknown"

   -i, --hardware-platform
          print the hardware platform or "unknown"

So, the triple from the output of uname -a correspond to machine processor hardware, in that order.

How the hardware platform impacts upon the choice for the programming language?

Some considerations below, but not a full answer by any means.

If your hardware platform is a small embedded device of some kind, then your choice of programming language is going to be directed towards the lower level unmanaged languages - you probably won't be able to (or want to) load a managed language runtime like the Java JVM or .NET CLR. This is down to memory and storage requirements. Similarly, interpreted languages will be out of the question as you won't have space for the intepreter.

If you're on a larger machine, it's more a question of compatibility. A managed language must run on a platform where its runtime is supported. In the case of .NET, that's Windows, or other platforms if you substitute the Microsoft CLR with the Mono runtime. In the case of Java, that's a far wider range of platforms.

what is the difference between virtual platform and real platform

What is the difference between platform and OS?

I cannot think of an official definition for platform. Platform can mean different things to different people depending on the context:

1. you can create applications for .net platform which may imply you're using Windows, but not the version (you may use mono on Linux as well)
2. the Java platform provides a basis for Java application, but does not tell you anything about JDK version, middleware products, etc
3. storage plaforms like SAN, NAS, etc
4. Virtualization platforms may consist of several components: hardware, storage, host OS, guest OS, etc.

Given your question I'd use the term platform as 'something above the OS':

Physical platform: Windows 7 + physical h/w

Virtual platform: VMWare + host OS + guest OS (Windows 7) + phyiscal h/w + virtual h/w

my 0.02 $

What do the terms platform and framework refer to?

The term framework is very well defined: a framework is very similar to a library, except that Control is Inverted. (Inversion Of Control is the defining characteristic of what constitutes a framework.) IOW: you call a library, but a framework calls you.

Another way to think about it, is that you write an application, but leave all the un-interesting details blank and use libraries to fill them. A framework OTOH is an application. It is an application which has all the interesting details left blank for you to fill in. (Of course, in the code you use to fill in the blanks you can in turn call libraries yourself. Also, the framework itself will call libraries to implement its inner workings. And, frameworks usually come bundled with a rich set of libraries which are tightly integrated with the framework. However, the distinction is still clear. Just because the framework and the libraries ship together in one package doesn't mean there is no distinction.)

The term platform, however, is not so well defined. It is also heavily overloaded. In the context of porting native applications, it usually refers to the combination of CPU ISA (e.g. x86, AMD64, IA-64, POWER, MIPS, ARMv9, Sparc), hardware architecture (PC, CHRP, PReP, Mac), kernel (Linux, NT) and base libraries (POSIX, Win32, Core Foundation).

In the broader context of software development, "platform" usually literally means "that which your code stands on". For a native application, that could be basically the same as above, for a JVM application it could be the JVM plus the JRE plus OSGI.

Basically, you can take the metaphor quite literal: a platform allows you (i.e. your code) to stand on higher ground than you could without it.

Will java machine code be the same on the same hardware?

TL;DR - No it won't.

The native code generated by the JIT compiler from identical bytecodes, by an identical Java release, and on the same OS could still be different.

• The generated code could depend on the physical hardware that the JVM is running on; e.g. the number of cores, the chipset, etcetera.

• The generated code could even depend on the inputs to the program. Before JIT compiling, the JVM uses a bytecode interpreter to run the code. This self-profiling gathers stats about branch probabilities, etcetera. These stats are used by the JIT optimizer. Since the code paths taken while running a program can depend on program inputs, different runs of the same program on the same machine may end up with the JIT compiler generating different native code.

• Since non-deterministic behavior during the JVM warmup can affect the stats gathered during self-profiling, it is even possible for the generated code to differ between runs of identical code on identical platforms with identical inputs.

That's the nice thing about HotSpot JIT compilation. It adapts to the environment, and what the application does. But this can be a problem if your primary goal is to get reproducible native code and reproducible performance characteristics.

What is the difference between a Linux platform driver and normal device driver?

Your references are good but lack a definition of what is a platform device. There is one on LWN. What we can learn from this page:

1. Platform devices are inherently not discoverable, i.e. the hardware cannot say "Hey! I'm present!" to the software. Typical examples are i2c devices, kernel/Documentation/i2c/instantiating-devices states:

   Unlike PCI or USB devices, I2C devices are not enumerated at the hardware level (at run time).
   Instead, the software must know (at compile time) which devices are connected on each I2C bus segment.
   So USB and PCI are not platform devices.

2. Platform devices are bound to drivers by matching names,

3. Platform devices should be registered very early during system boot. Because they are often critical to the rest of the system (platform) and its drivers.

So basically, the question "is it a platform device or a standard device?" is more a question of which bus it uses. To work with a particular platform device, you have to:

1. register a platform driver that will manage this device. It should define a unique name,
2. register your platform device, defining the same name as the driver.

Platform driver is for those devices that are on chip.

Not true (in theory, but true in practice). i2c devices are not onChip, but are platform devices because they are not discoverable. Also we can think of onChip devices which are normal devices. Example: an integrated PCI GPU chip on a modern x86 processor. It is discoverable, thus not a platform device.

Normal device driver are for those that are interfaced to the processor chip. before coming across one i2c driver.

Not true. Many normal devices are interfaced to the processor, but not through an i2c bus. Example: a USB mouse.

[EDIT] In your case, have a look to drivers/usb/host/ohci-pnx4008.c, which is a USB host controller platform device (Here the USB host controller is not discoverable, whereas USB devices, which will connect to it, are). It is a platform device registered by the board file (arch/arm/mach-pnx4008/core.c:pnx4008_init). And within its probe function, it registers its i2c device to the bus with i2c_register_driver. We can infer that the USB Host controller chipset talks to the CPU through an i2c bus.

Why that architecture? Because on one hand, this device can be considered a bare i2c device providing some functionalities to the system. On the other hand, it is a USB Host capable device. It needs to register to the USB stack (usb_create_hcd). So probing only i2c will be insufficient. Have a look to Documentation/i2c/instantiating-devices.

---

Related Topics