Eric, >> How does DOS ever detect that any hardware is "unreliable"?? > > I do not know, but earlier in this thread, somebody said that > the numbering of FAT filesystem exists, among other reasons, > to help DOS detect floppy changes even if there is no change > line available.
The FAT file system is defined by DOS, and I want UIDE/UIDE2 to have NO run-time "dependencies" on the DOS system. > As you know, int 13.15 can even report that a floppy has no > change line at all ... I did not know this, but no-matter. UIDE/UIDE2 check the BIOS data table for diskette change-line availability, and they also check the table for diskette "media change" status prior to any diskette read/write. In my opinion, this is the same as doing an Int 13h request addressed to a diskette. BUT, this AVOIDS "re-entrant" Int 13h calls, as UIDE/UIDE2 have already been "entered" due to the I-O request! I believe such calls are DANGEROUS, and that is a big reason why my drivers do NO such calls (Int 13h, Int 21h, etc.) at run-time! They also do NOT permit re-entrant I-O requests, i.e. one more I-O before the current I-O has completed! Helps to keep UIDE/UIDE2 safe! > Int 13.16 which actually queries the change line can return > invalid command, drive not ready / not present, no change or > "change line active or not supported". NOTE that calling the > check also clears the status, so only ONE caller will notice > each change and only ONCE! Lbacache takes special care here. UIDE/UIDE2 do also, in fact by NOT issuing any Int 13h diskette requests at run-time! They check the BIOS data table instead! > As you see, a very long chain of events exists around all > DOS block device related things ... Too complex, TOO MUCH for a 7K-byte driver like UIDE2 (7.5K for UIDE), and rather irrelevant, to me. I have noted before that UIDE/UIDE2 process only Int 13h I-O requests and so are NOT, in fact, either a "block device" driver or an actual "DOS driver". At run-time, they work as "BIOS drivers" and are absolutely NOT concerned re: DOS, only with Int 13h I-O calls, or "subroutine" calls from SHSUCDX and/or external drivers that desire caching. >>> I agree that it is nice to disable floppy caches, but maybe >>> the kernel actually does something detectable ... >> >> What do you mean "maybe"?? You and others are the "kernel >> experts" for FreeDOS, not me, as I still run V6.22 MS-DOS!! > > As you see above, handling of floppies and their changes is > a complicated thing which is not easy to walk through, even > for me :-) You should find out exactly what the FreeDOS kernel does, if it does anything "special" at all, when handling a diskette media- change. If it does NOTHING "special", then you may understand exactly why I tend to AVOID any DOS functions, except during my drivers' initialization. > As far as I can tell, you could make int 13.0 (disk reset) > and reads of the boot sector flush events ... Never heard of "boot-sector flush events", and in any case what you ask here would demand "re-entrancy" in UIDE/UIDE2. Like I note above, I want to AVOID re-entrant calls to the BIOS or any run-time calls at ALL to DOS. >> UIDE2 to run on all DOS systems. Checking the BIOS media- >> change status has always worked in my drivers for diskettes > > See above - if you ACTIVELY call int 13.16, you could "hide" > the floppy change from DOS because int 13.16 returns changed > status only for the first call after a disk change even with > working change lines ... "NO re-entrant calls!", I say again! Having UIDE/UIDE2 issue an Int 13h of their own WOULD require re-entrancy! >> Finally, as noted before in this forum, UIDE and UIDE2 make >> NO run-time DOS "system calls" and I also want to keep THAT > > I agree that it is good to not call DOS in a DISK cache and > actually it should not be necessary to call DOS either :-) You can bet your [rear-end] on THAT issue! ;-) > Note that things might be different for block device based > caches instead of BIOS / hardware based caches like ours... No argument there, since anyone can note the memory usage of UIDE/UIDE2/LBAcache versus SMARTDRV/NCACHC2/etc.! >>> By the way, any chance to work around the VirtualBox >>> huge-delay problem? >> >> Not without knowing WHY they take such a huge delay! In any >> case, UIDE and UIDE2 must "scan" for PCI-bus devices... > > If I understand your code correctly, you scan all 256 bus, > 32 device and 8 function locations which can be expressed, > using the BIOS ... NO, I do NOT scan busses!! I scan PCI class, subclass, and function codes, as I would rather NOT have to determine WHAT actual busses are present. A class-code scan is a lot more "generic" and will TELL me what PCI "bus" a device is using! >>> If you prefer the BIOS way, would int 1a.b103 be an option? It >>> scans by PCI class so you do not have to loop over bus/device. >> >> My drivers are ALREADY doing a PCI scan by class-code... > > Not by iterating over locations, you mean? Certainly NOT, as only the PCI BIOS can tell me where it has "assigned" each I-O device to run!! >> Doesn't matter. A scan for devices by PCI class-code returns >> only devices that match the requested class/subclass/function > > In that case, the BIOS itself might be to blame - if it > scans all possible locations instead of only used ones > to return the scan-by-class-code result list ... PCI V2.0C and later versions have all worked just FINE, until the rather poor emulator know as "VirtualBox" appeared, using its MISERABLE "emulation" logic for the Intel PIIX3 chipset!! If they DO NOT have such "long delay" trouble with their ICH9 "emulation" logic, do you REALLY expect we should believe the PCI BIOS logic is now at fault, after almost 20 years?? The "VirtualBox" brats should take a long-hard look at their ICH9 v.s. PIIX3 routines, and CORRECT those for the PIIX3!! > ... You also have to assume that the BIOS does not cache > anything in that call, so to get a LIST of devices for one > class, you have to ask the BIOS in a loop "what is the first > device for that class? the second?" and so on, until > an error is returned: The BIOS might have to walk the > whole addr space for each time, counting devices of > the requested class code along the way, and might do > so in a non-efficent way / direction in VirtualBox... That is a problem ONLY for "VirtualBox"! In all other cases and when using a real "hardware" PC, it does NOT slow down my drivers at all, or anyone else's AFAIK! If the colleges no- longer teach "C" BRATS how to write decent and efficient LOOP code, then GAWD HELP US!! > The best way to be sure to NOT lose time, in particular > given the quality of certain modern BIOSes, seems to be > to walk the right parts of the PCI address space in own > code and use port I/O instead of high-overhead BIOS int > calls. I mean int 1a.b1 is documented to "use up to 1kB > of stack" while reading a PCI register using I/O takes > only a few handful lines of Assembly code in pcisleep. Sorry, but I am NOT going to "bash" the PCI BIOS, not after it having been used successfully for almost 20 years! Nor am I going to change my drivers to have some other "scheme" in their device-scan, merely to handle the "possibility" of a bad BIOS! If a BIOS cannot run a proper PCI scan, it is NOT going to "last long", before many more people than just me "gripe" REAL LOUD at its vendor, and the vendor shall be forced to FIX IT! The problem here is "VirtualBox". It, AND ONLY IT, needs to get FIXED in many areas! All else, which has run O.K. before they came along, needs NO fixes nor any changes! >> any case, no one has ever complained about the speed of UIDE's >> or UIDE2's initialzation, except when running "VirtualBox"! > > True - on real hardware, even the worst case situation > of scanning for controllers might be done in seconds, > only VirtualBox is known to take minutes. Then Why-in-HELL do you suggest any OTHER "possibilities", as in much of your comment above?? >> Also, better if you refer to "UIDE" in general... > > Honestly I am no expert in any UIDE* source, as things > are very packed and rank small size over easy to read > structures of the code ... I always did get the job of being "The poor bastard who had to make it WORK!", and so I make no excuses for the complex nature of my code! UIDE/UIDE2 do all that they do in only a 7.5K or 7K-byte driver, whose run-time code is 5.2K/4.5K, written in assembly-language (which automatically disquali- fies most "C" types from understanding it). Do try to understand, as my damn ex-wife never did [part of why she BECAME my ex- 32 years ago!!], that I have a REASON for everything I say and do, same as for everything in UIDE and UIDE2!! Jack R. Ellis ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
