>> This doesn't belong on Freedos-user then. > > Maybe Czerno / Bertho is not on freedos-devel?
Then they should subscribe to it. > Or maybe there is > simply too little traffic on freedos-devel, so he preferred to > give it a try on freedos-user... I am CCing -devel here, I'm keeping -user as the main recipient until OP moves. > If your block device driver shows the DOS kernel a device > with 512 byte per sector "virtual" sectors then the kernel > will happily use 512 byte per sector BUFFERS for them... Oh, that's what you meant. >> This is wrong. Block drivers directly interact with DOS and its >> buffering >> scheme. If what you want is to circumvent the restrictions imposed by >> DOS's buffering scheme (for example, current 512B-/2048B-sector limits >> of >> the FDK) you'll have to write your own (FAT) file system driver which >> interfaces downwards with the block device driver (in your case, >> USBASPI.SYS) and upwards with DOS's file system redirector interface. > > This is also wrong. Because the filesystem still is FAT > and the kernel does already understand FAT, your driver > can present your 4 kB per sector disk as a BLOCK device > or in other words: As a bunch of sectors. However, your > driver has to transform what the DOS kernel sees of the > boot sector and BPB, because the whole idea of having a > 4 kB disk support driver for 512 byte per sector DOSes > is that it shows the kernel a bunch of 512 BYTE SECTORS > (virtual ones) instead of showing the real 4 kB sectors. Apologies, I misunderstood the request. I should have thought of your (Eric) sector size downwards "transformation" suggestions of earlier. > This DOES circumvent the limitation of the DOS kernel: > The kernel only sees 512 byte per sector "blocks". But > as explained above, now your driver will have to spend > at least 4 kB of buffer space for the transformations. This is accurate. >> redirector interface is what file system drivers for non-FAT file >> systems >> (eg *CDEX) and networked file systems use to make their files accessible > > That would mean that you duplicate the whole logics of > understanding the FAT filesystem into your driver. Correct. > NOTE: Transformation of sector sizes is easiest in FAT32. > Other FAT sizes may take more effort. I don't think so. Why would they? Cluster size stays the same, no FAT-related special handling (which would be more complicated for, say, FAT12) is necessary as far as I can tell. > Also, you can only > transform from 4096 byte units to 512 byte units if the > filesystem is at most 2 Terabytes and cluster size is at > most 32 or maybe 64 kilobytes. Right, the usual 32 (or for some OSes, 64, 128, etc) KiB cluster size limit still applies here. > You CANNOT transform from > 512 to 4096 usually, as format tools do not take care to > align things in a way that would make this easy enough. True. > Of course you CAN transform back a FAT32 partition from > an originally 4 kB per sector disk to 4 kB sector disks > after you accessed it in 512 byte units and even if you > actually stored it on a physically 512 byte per sector > disk and used it there. This only needs the boot sector > transform to be transformed back :-) Right. Even a file system originally created with 512 B sectors could be "transformed" into using 4 KiB (or other > 512 B sizes) sectors if the file system structures (reserved sector number, FAT size, root size. And the cluster size must be >= target's sector size) are properly aligned; as you implied. regards, C. Masloch ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
