SCIENTIFIC-LINUX-USERS Archives

December 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Fri, 7 Dec 2012 11:27:09 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (101 lines)
Please do not confuse 3 separate issues:

1) Linux userland: this is pretty much universal and will
   run on any CPU as long as you have a cross-compiler
   and as long as the "autoconf" tools do not try too hard
   to prevent you from cross-compiling the stuff.

2) Linux kernel: is also pretty much universal and assumes
   very little about the CPU. There *is* some assembly code
   that needs to be ported when you move between CPUs (say
   from hypothetical SuperARM to hypothetical HyperARM). I believe
   current versions of Linux kernel have this support for
   all existing ARM CPU variations.

3) Linux device drivers: in the PC world devices are standardized
   around the PCI bus architecture (from the CPU, PCIe looks like PCI,
   on purpose) and most devices drivers are universal, so if you
   have a PCI/PCIe based ARM machine with PC-type peripherals ("South Bridge",
   ethernet, video, etc), you are good to go. If you have an ARM machine
   with strange devices (i.e. the RaspberryPI), you have to wait
   for the manufacturer to release the specs, then you can write
   the drivers, then you can run Linux. Rinse, repeat for the next
   revision of the CPU ASIC (because they moved the registers around
   or used a slightly different ethernet block). It helps if you have
   some standardized interfaces, for example on the RaspberryPI you have
   standard USB, so you can use "all supported" USB-Wifi adapters right away.

4) boot loader: is different for each type of machine, each type
   of boot device media. period. (Even on PCs there is no longer any
   standard standard - some use old-school BIOS booting, others use EFI boot,
   some need BIOS/ACPI help, some do not).

This makes it 4 issues, if you count the first (linux userland) non-issue.


K.O.


On Fri, Dec 07, 2012 at 01:01:36PM -0600, SLtryer wrote:
> On 10/23/2012 12:37 PM, Konstantin Olchanski wrote:
> >An "ARM platform" does not exist.
> >
> >Unlike the "PC platform" where "PC hardware" is highly standardized
> >and almost any OS can run on almost any vendor hardware,
> >the "ARM platform" is more like the early Linux days where instead
> >of 3 video card makers there were 23 of them, all incompatible,
> >all without Linux drivers. If you had the "wrong" video card,
> >too bad, no soup for you.
> >
> >In the ARM world, there is a zoo of different ARM processors,
> >all incompatible with each other (think as if each Android device
> >had a random CPU - a 16-bit i8086, or a 32-bit i386, or a 64-bit i7 -
> >the variation in capabilities is that high).
> >
> >Then each device contains random i/o chips connected in it's own
> >special way - there is no PCI/PCIe bus where everything is standardized.
> >There are several WiFi chips, several Bluetooth, USB, etc chips. Some
> >have Linux drivers, some do not.
> >
> >As result, there is no generic Linux that will run on every ARM machine.
> 
> Not to be argumentative, but I always believed that the advantage of
> *nix* was that it could be ported to numerous platforms, regardless
> of hardware.  You even mention the "early Linux days," when there
> was little or no standardization of PC hardware.  Yet, the platform
> didn't disappear from use simply because there might have been
> porting issues, most of which were caused more by proprietary
> secrets and hardware defects than the ever-present fact of diversity
> of hardware.
> 
> But one could make the same argument even today:  That there are
> many different CPU platforms, e.g., and that they are not
> standardized.  One example I am thinking of is the Intel v. Amdahl
> CPU compatibility issue.  Even though most of the Linux system will
> run on either without modification, there are still some unique
> issues to each of them; from having worked and studied VirtualBox,
> there are differences in how each manufacturer chose to implement
> the ring structure that permits virtualization to work as nicely as
> it does on these platforms.  For the most part, they are compatible,
> but the kernel developers have to be aware of certain implemention
> issues, including a bug in the Intel CPU platform that requires a
> VirtualBox workaround (for optimizing the code or something; I
> forget).
> 
> And this is in addition to Linux supporting umpteen different
> processing platforms besides the x86 types.  New hardware appears
> constantly, and some Linux user somewhere wants to use it on their
> system.  I feel that variety of hardware and variation in hardware
> implementation is a fact, and a main reason why Linux and Unix are
> so powerful and ubiquitous.
> 
> Now I just hope no one will hold me to this and insist that I
> actually port Linux to all these different hardware configuration!
> I'm not signing up; I'm just pointing out what I think is reality.

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

ATOM RSS1 RSS2