--6e7ZaeXHKrTJCxdu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 04, 2006 at 09:42:30AM -0800, jonathan@dsg.stanford.edu wrote:
> In message <E515D5E7-5339-406A-A441-28E60A1364EF@shagadelic.org>,
> Which tends to suggest that the current UDF code probably won't work
> on a wrong-endian host. Has UDFit been tested by moving a single
> physical media device between big- and little-endian hosts?
> Ideally, both write-on-big, read-on-little, and write-on-littel,read-on-big.
> 
> If it hasn't, that should be tested and verified to work beforte the
> code is imported. 

The current code is still read-only :-/ and allthough it doesn't byswap all 
structures in advance it byteswaps the values retrieved from them when 
requested. This has to do with the quite `flexible' structures with lots of 
concatinated tables and variable offsets etc. Translating them all in one 
go would require quite a lot of code and is error prone. I've seen it done 
before and believe me, its not a nice thing to do.

My in-kernel UDF implemenation is a re-implementation of 
pkgsrc/misc/udfclient only a lot cleaner and simpler. UDFclient has and is 
run on 32 or 64 bits machines and is endian-proof.

My in-kernel UDF implementation has been given special care to be 
endian-proof.

Reinoud


--6e7ZaeXHKrTJCxdu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ7wSnoKcNwBDyKpoAQIxawf/RP9P4lMWPIg1eTxNV1BexgndvOGzlBFF
7UU1fjfsTKKfYDihVS/q6tdtW4LPkJRu+lGTDKWcp9xH3sLK25GftG2bv0MXMpU7
NtoqY9nfGkc4tXqe6G6hV2ltUXJyd5ANc6pVgytgVq4GQtfQeW73R7LF7qWlIMQu
vpyHOLsSym+SVhzDRpP0FS2LtPQ0iZ0991NfX4S4R5dSJ2rhq8Qbl8G6EsUUTaZs
1znJ6yHpOV+VEVB5ZWdBO/l8etMYZanYuwwDtVJSVdwIvV3zx2vR6V/Px43w2hRZ
eRklyvU6F66ZiFUoBSOxcvAfQEXFgZ2+nE4ggWGInepYmwPJlLz9dg==
=O2FW
-----END PGP SIGNATURE-----

--6e7ZaeXHKrTJCxdu--