It "depends", as the saying goes.
SPARC (like Motorola 68000 series) is big-endian, and if
the system were as bad as you imply in that kind of hardware,
then you would not be reading any of the Linux lists now
going thru vger.rutgers.edu.
> Drivers, filesystems etc...
> must be written in a big-endian compatible way, all 16bits, 32bits
> access to hardware or to external data structures must be converted
> using some macros defined in the linux kernel. A lot of drivers were
> written specifically for intel and are not big-endian compatible...
> So linux is more reliable in little endian.
For you I would be more carefull when claiming something like
that... As far as I know, all truly commonly used drivers
(including most of the ones using PCI bus) are written using
platform hiding interface macroes. (For example there are
THREE (or four?) ways of doing inb() in different Alpha systems.)
(Mind you, there is the dimension of little-/big-endianity,
but also 32/64 bit issues harm some drivers.)
Having touched a lot of drivers in Linux kernel, I do know
that there are ones which you don't get to *any* other than
their original intel based platform. Said drivers, however,
are an exception.
Now a semi-embedded SH4 -- how much there might in the end be
hardware easily drivable with existing drivers ?
Filesystems work just fine (EXT2, MINIX, RAMDISK, NFS, ROMFS),
as does the networking, basic memory management, scheduling, ...
Driving e.g. IDE, serial ports, LEDs will likely need full-
custom interface chip drivers.
If the SH4 does not have a MMU, then things may get a bit more
sticky -- it will be hard, if not outright impossible, to run
fully in usermode residing processes.
> LERDA Patrick
/Matti Aarnio <matti.aarnio@sonera.fi>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/