From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5ad9b73d1b437d040f85dcbb9b804b2e@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun, 14 Sep 2008 12:00:52 -0400
To: 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] dossrv vs. camera sd fat
Topicbox-Message-UUID: 10f2737a-ead4-11e9-9d60-3106f5b1d025

it seems that the check in dossrv/dossubs.c:/^isdosfs does not
agree with the layout on the sd stick in my camera.

it turns out that although the first and last bytes of the magic
(jump instruction) have traditional values, the jump offset is
0.  i suspect this is an oversight.  (who boots from a camera
sd?)

this is the change i made last night that at the time seemed
a bit over-agressive:

; diff -c dossubs.c /n/dump/2008/0913/sys/src/cmd/dossrv/dossubs.c
dossubs.c:22,31 - /n/dump/2008/0913/sys/src/cmd/dossrv/dossubs.c:22,29
  	/*
  	 * Check if the jump displacement (magic[1]) is too short for a FAT.
  	 */
- 	if(buf[0] == 0xEB && buf[2] == 0x90 /*&& buf[1] >= 0x30*/)
+ 	if(buf[0] == 0xEB && buf[2] == 0x90 && buf[1] >= 0x30)
  		return 1;

i thought perhaps the test should be

- 	if(buf[0] == 0xEB && buf[2] == 0x90 && (buf[1] >= 0x30 || buf[1] == 0))

however, after a bit more digging, the ecma-107 standard says:
(http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-107.pdf, page 11.)

"This field shall be reserved for system use.
Its content is not specified by this ECMA Standard
and shall be ignored in interchange."

it seems like the isdosfs checks are actually contrary
to the standard, though they generally seem to work
i assume since most fat are ment to be bootable.

anyone with any perspective on this?

- erik