> No such change is needed, large sectors work 'out of the box'. With all manufacturers and versions of DOS, or just with MS-DOS 7+?
> The (ugly, imo) kernel mod which Bret's programs need is required > only because his system has to load after "sysinit" is finished > processing installable device drivers and sizing its internal buffers. I totally agree it's ugly, and I wish I knew of another way, but is the only thing that actually works reliably. Even creating an installable device driver with large sectors only works with MS-DOS 7+; MS-DOS 6 and below require the kernel patch. I've never tried, but PC-DOS may also work with the patch (PC-DOS and MS-DOS have the same roots, but I don't know exactly how far back support for large sectors goes compared to the rift between MS and IBM). > Aren't you mixing apples with oranges ? ASPI and "int 13" aren't at > the same protocol level or "layer". Actually, they are: they both provide the low-level (sector-level) access to the disk. If you have one you don't need the other -- one doesn't "ride on top" of the other. If they were different layers, you would require both of them at the same time. However, you can, as you state below, provide both interfaces in the same driver, or add an additional driver to emulate the interface that's missing (just make sure to appropriately manage the possibility of having more than one drive letter for the same partition). If you have an INT 13h interface, though, there's no good reason I can think of to provide an ASPI interface (which is why I didn't do it in my driver). The reverse is not true, IMO. The reason I say is because all of the DOS utilities and drivers that need low-level access to the disk (partitioning, formatting, defragging, caching in some cases, etc.) use INT 13h, not ASPI. I will admit that most of them (including those from MS) don't work properly with anything other than 512 byte sectors, but I expect that will be remedied someday, at least with the FreeDOS utilities. > I'm not 'implementing' ASPI, I'm building over it. I understand -- I just think it's a mistake, and you should be building over INT 13h instead. I certainly understand why you did it, but just think it's not a good strategic (long-term) decision. Just my opinion, though. > ... OTOH it works with OHCI.UHCI and more importantly hi-speed EHCI > (or more, provided you can find the ASPI provider). Which I think is the biggest reason you designed it the what you did -- it's a tactical (short-term) choice, not necessarily a strategic one. Undoubtedly others will benefit from it, as you have. > And BTW I have just coded-in full width 32-bit sector numbers, which > assuming 4K sectors provides for access to devices up to 16 > "tebibytes"... That's great, though you may want to consider doing 64 bits (the new version of my driver that I'm working on does that, to ensure adequate support for GPT and the 64-bit INT 13h extensions). ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
