This is "in-reply to" Bret Johnson's -2012-02-22 01:14- [freedos-user]

Please once more, notice I've *switched lists* in favor of [freedos-devel].

....

>> Uh, here I'm confused, not following any more, please elaborate your
>> point. Assuming we've loaded  USBASPI.SYS [which provides ector
>> access to the external disk using "SCSI" commands], my hypothetical
>> driver wishes to support one or more FAT partitions on that external
>> disk.

Bret wrote :
> It depends on exactly what your driver does.  It sounds like you're intending 
> to essentially make a replacement for DI1000DD.SYS. 

Maybe I should clarify. ATM I'm evaluating diverse options including that 
suggested by Eric Auer, in terms of usefulness and generality vs. quantity of 
work involved. But yes my original idea and what I was referring to in the 
conversation with you is to write a /replacement/ for DI1000DD - with provision 
for FAT partitions on disks having 4K sectors. 

And to answer a question posed elsewhere, yes I have confirmed USBASPI.SYS (at 
least the particular version 2.27N? by Novac-Yaya DIY) does handle 4K sector 
access properly on real media ; which is the main reason I'm considering this 
approach.

Bret wrote:
> If so, you're going to need to "coordinate" your installation with 
> DD1000DD.SYS, in case the user tries to install both at the same time. 
> (.....)

Oh, now I see what you had in mind. Coordination, hum yes, Ill try to keep that 
in mind for a... final refinement ;=)

> I (and you, apparently) are assuming that USBASPI.SYS supports 4k sectors, 
>but I would actually verify that before I went very far.

Answered above.

>> If, however, you're going to do what Christian (and maybe Eric?) was 
>> thinking and essentially install a "shim" between DI1000DD.SYS and the 
>> kernel, things are a little different.  Such a shim could work even on
>> non-ASPI disks (such as those provided by Georg's or my USB drivers), but
>> should abort installation if the kernel natively supports 4k sectors. In >> 
>> this scenario, there's also the potential issue of hot-pluggable disks 
>> (which are supported by my USB drivers, but I don't think are supported
>> by USBASPI or Georg).

Another yet possibility : have a driver loaded /before/ DOS (for instance from 
MBR or Boot sector code, ala PLoP) which would provide int 13h access to the 4K 
disks. Then a DOS kernel should mount those disks natively without any 
additional drivers, /provided/ it is 4K sector compatible. My current 
understanding : MS-DOS /is/ compatible (possible bugs to be checked?), FreeDOS 
hopefully will be soon...

After I suggested it, the last PLoP version added experimental support for 4K 
sectors on USB, it doesn't work unfortunately - the developper has no means to 
test, and has been unwilling to provide sources or enough information to make 
debugging comfortable. 

>> Do you mean to say "non-IBM" ? UIAM again, the "IBM" (should be
>> called "MS") formats are the usual FAT disks. IOW "non-IBM" is when
>> attribute bit 13 = 1.

>No, it's the other way around.  If bit 13 is set, it means "IBM Format",
>but that doesn't equate to "MS".  Here's a quote from an old book I have,
>"DOS Programmer's Reference", 2nd Edition, by Que, which gives the
>practical explanation of what the bit means, specifically regarding
>function 2, "Build BPB":

"A one sector buffer is passed to this routine.  If the non-IBM format bit in 
the device attribute word is set to zero, the buffer contains the first sector 
of the FAT and should not be changed.  If the bit is set, the buffer can be 
used as a scratch area in which to build the BPB."

>It doesn't have anything to do with non-FAT.

Oh, good to know. It' unclear still what these options were meant for... Maybe 
a divergence of opinions between the teams at MS/big Blue ?

>Bottom line for safety in the driver: ignore the setting of the bit,
>assume you can't change the buffer, and assume the buffer does not contain 
>the first sector of the FAT.

Thanks

-- 
Czerno

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to