Geert,
I thought the 'discard' marks the start of no longer used options (i.e. option processing stops at discard). My bad.You got me, I never looked at it that way ;-) No, it comes from commit 681142f9211b23e6aa2984259d38b76d7bdc05a8 ("fat: make discard a mount option")
Now I'll have to go and look what that is about :-)
Given that I could not even remember what it was that I had to do to the FAT code to get it to what it does now, we best leave it at that. Schroedingers cat, and all that :-)commit cc9c5fc236c0d02cae44c2fbcc8ffa3ae5e517b6 ("Atari FAT updates") more or less summarizes it. It's the logic which decides whether the FAT is 16-bit or 12-bit.
Yep, I had seen it in the log message there when I had a look at what still was on m68k-queue. Just couldn't remember any of that without refreshing my memory. I'm still being bitten by the limit on logical sector size for FAT - partitions larger than 128M either can be read from Linux (sector size 4k) or TOS (sector size 8k) but not both. Has anyone found a workaround for this? In other news, SCSI on the Falcon is still broken - timeouts for SCSI commands are started by the block layer, but commands cannot be guaranteed to get queued in the lowlevel driver unless the lowlevel driver has access to the SCSI DMA right away. Upon timeout, the request isn't actually found on the lowlevel queue in case the queue request had to wait. I'm unsure what the correct strategy is here: defer queueing requests by pretending the driver is busy, or queue requests and try to kick off the coroutine as soon as DMA gets available? Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
