Niels Mvller wrote: > > Glenn McGrath <[EMAIL PROTECTED]> writes: > > > If hurd was on different endian type machines would it all be taken care > > of by the microkernel anyway ? > > No, to have the kernel change the byte order as seen by user processes > would be a waste of cpu time, if possible at all. (Some cpu:s can use > either byteorder, but not x86). > > > I guess i should just find a way to ignore endian related code when > > compiling under the Hurd. > > > > Anyone have any pointers to good docs on endian issues? > > Basically most endian dependent code are performance hacks (and most > I've seen are not very important optimizations either). Let's say > that you're reading some data structure from the network or from raw > disk (I'm guessing you are reading the partition table...). > > You get the data from the hardware as a sequence of bytes (a string), > and the spec for the format says how to parse it. For instance, the > spec may say that there's a 32 bit unsigned integer integer, stored as > four bytes, most significant byte first (i.e. big endian). Assuming > only that char is eight bits and long is 32 bits, you could write > > /* Get pointer to storage, e.g. a pointer into a raw copy of the > * partition table. */ > unsigned char *buf = get_storage_pointer(...); > > unsigned long value = (buf[0] << 24) + (buf[1] << 16) > + (buf[2] << 8) + buf[3]; > > The code above is endian-clean. It obviously depends on the byteorder > used in the partition table, but it does *not* depend on the byteorder > of the machine executing the code. An endian-dependent optimization > might replace the second statement with > > unsigned long value = *(unsigned long *) buf; > > This will work sometimes: if the code is executed on a machine that > uses big-endian byteorder, and if the data pointed to by buf is > properly aligned for a 32-bit read accesses. > > And the endian-ness used on the disk should be fixed and independent > of the endian used by the cpu, or else you cet into trouble when > you physically move the disk from the pc to a machine with some other > endianness and you try to read it. > > Early linux versions of the linux-m68k port used a different > endianness for the datastructures in the ext2 filesystem, but today I > believe you can swap disks with ext2 filesystems on them between all > of linux-x86, linux-m68k, linux-sparc, ... > > I hope this makes the issues clearer. >
Yes, it all makes sense now, thanks for the good description. Glenn
