#3 partial OS X port for efsl-0.2

[garthz]

Today I attempted a port of efsl-0.2 to Mac OS X, which
is what I use for microcontroller development.
Ultimately I gave up when I discovered that the
big-endian problems really permeate the code; I was
unwilling to go line by line to find every place where
a FileRecord was manipulated. But I did fix a few
other bugs and make progress, so hopefully this will
still help a future attempt.

Attached is a complete context diff patch taken between
the CVS version of the efsl-0.2 tree and my modified
files. Below are the notes I took during the attempt.

By and large the support for OS X would be nearly the
same as for Linux apart from the PPC big-endian question.

==================================================

Summary of changes during attempt to add Mac OS X
support to libefsl.

My attempt was ultimately stymied by the fact that
big-endian support was inconsistently applied by
the authors of the code. Although ex_setb16 and
ex_setb32 were defined, they were only used in a
couple of cases, and the majority of cases where
directory information is manipulated incorrectly
write native byte ordered data structures back
onto the disk. I think fixing this will involve a
line by line examination of several files to check
all in-memory manipulation of FileRecord
structures, which I was unwilling to attempt.

I worked with the CVS version of efsl-0.2 since it
promised to be the most stable. A cursory glance
at 0.3 indicates that the big-endian issues are
only partly solved; e.g., mkdir() in vfat/ui.c
still writes out direntry in native byte order.

---Garth Zeglin, 2006-10-05

================================================================

Here is a summary of changes I made to efsl-0.2 up
to that point, including some general bug fixes.
I've also attached a patch file.

copied config-sample-linux.h to config-sample-osx.h
copied Makefile-LINUX to Makefile-OSX

in config-sample-osx.h
added HW_ENDPOINT_OSX define

in types.h
added HW_ENDPOINT_OSX section
also had to add uint16 and uint32 definitions

in interface.h
added HW_ENDPOINT_OSX to case for interfaces/linuxfile.h

BIG_ENDIAN is a keyword in
/usr/include/{ppc|i386}/endian.h, so I renamed it
EFSL_BIG_ENDIAN in several places:
src/extract.c
inc/extract.h
(I think it is also a standard keyword under
linux if endian.h is included.)

in debug.h
added HW_ENDPOINT_OSX to the case for
HW_ENDPOINT_LINUX_ALL

(the data files for the regression test are not in
the distribution, so I can't run that as-is)

(linuxutils compiles as-is with a few warnings)

in extract.c:
it looks as if ex_getb16() and its kin do a
double byte swap in the case of BYTE_ALIGNMENT
being undefined on a big-endian architecture;
for some reason both the ltb_end16 macro and an
explicit byte swap are coded. I removed the
ltb_end16 and ltb_end32 macro calls, since the
explicit byte swap will be correct on any
architecture.

in ls.c:
the DirList FileName field is treated as a C
string by list.c, but ls_fileEntryToDirListEntry
did not guarantee this, and it was picking up
the file attribute byte at the end; I added a
line to zero the last byte.

in linuxutils/mkdir.c:
the error return on mkdir had inverted sense; it
would report an error on a zero value rather
than non-zero value

================================================================
other questions and comments:

I was surprised to see a function memCpy with
the arguments reversed from the standard libc
memcpy. That seems unnecesarily confusing.

I found ls_getNext() does return the volume
label, which seems to have an attribute value of
0x28 (ARCHIVE+VOLUME). This surprised me at
first, but is at least consistent. This was on
a FAT16 created under OS X using hdiutil.

[garthz]

patch for partial port of efsl-0.2 to support Mac OS X