Jack, kernel people (now CCed), >> When DOS detects an unreliable floppy change line hardware, >> it should use the floppy label / serial / similar to detect >> changes in software ... > > 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. As you know, int 13.15 can even report that a floppy has no change line at all. MS DOS might, on top of that, have a list of BIOS versions with "weak" change lines? Related kernel sources: init_readdasd, make_ddt, maybe also DosDefinePartition. Apparently FreeDOS has drive types hard- disk, floppy with change line, and "other" here... 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. Related kernel sources: FL_DISKCHANGED, fl_diskchanged, floppy_change, mediachk, diskchange... If you have NO change line, diskchange returns "not changed" if you very recently accessed the disk, and "unknown" otherwise, I believe?) For M_DONT_KNOW, mediachk returns "disk changed" iff the serial of the filesystem changed compared to the current DDT info. Finally, media_check is described to trigger on "unknown, changed or definitely changed". It does setinvld and calls the D_BLDBPB block device driver function and converts the BPB to DPB then. Note that int 21.7302 "get ext dpb" calls flush_buffers, flags a fake disk change, calls media_check. DosGetFree can behave similarily depending on arguments... Maybe update_dcb is also related. I think D_BLDBPB is done by rqblockio and the bldbpb function and getbpb, which also calls RWzero to re-read the boot sector? As you see, a very long chain of events exists around all DOS block device related things, but that is necessary to be fully compatible with MS DOS... You also see that I did NOT mention calls to int 13.0 disk reset here - I have not seen any (apart from fl_reset / FL_RESET calls in reaction to I/O errors deeper in the RWzero chained LBA_Transfer). >> I agree that it is nice to disable floppy caches, but maybe >> the kernel actually does something detectable in REACTION to >> detecting a floppy change? For example it might issue an Int >> 13h "drive reset" command which in turn can be caught by the >> UIDE2 driver and treated as a "flush cache for THAT drive" >> event? ... > > 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 :-) > Also, I say again that I am NOT interested in any "specific > logic" from the MS-DOS kernel, or the FreeDOS kernel, or in > fact ANY kernel, for detecting diskette changes. My worry > is that such logic may NOT be "generic", and I want... As far as I can tell, you could make int 13.0 (disk reset) and reads of the boot sector flush events. That might flush a bit more often than necessary, but at least not LESS often than necessary, assuming that you ALSO trap int 13.16 return values already and trigger flushes when you see change line activity :-) > 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... > 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 :-) Note that things might be different for block device based caches instead of BIOS / hardware based caches like ours... >> 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. You could save a lot of time by scanning only those bus numbers that are used and not scanning sub functions for devices that are installed at all. It also is a lot faster to use mechanism #1 port I/O and not call the BIOS for each access, but you might be using the BIOS deliberately to also support ancient mechanism #2 boards? > If the "VirtualBox" people cannot fix the huge delay... I think UIDE2 now takes 2-3 minutes on VirtualBox when that uses a virtual PIIX3 chipset, so if you really do a scan of all locations, scanning only those locations where a bus exists will only take a few seconds even in BIOS style :-) For example my very new mainboard still has "only" 7 out of 256 bus numbers in use, big diff... >> 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? Then maybe it would be better to change to iterating (in efficient way, skipping unused areas) over locations and check for each device whether it has one of the desired class codes? I mean as opposed to letting the BIOS scan all locations for each class-code-of-interest, in case you have multiple class codes that UIDE2 is interested in? > 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. 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... > so I lose no time by checking unnecessary busses/devices. 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. > 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. On the other hand, instant on real hardware and seconds on Virtual- Box would of course be even better and worth trying :-) > 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... Regards, Eric ------------------------------------------------------------------------------ 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-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
