Jack, >> the numbering of FAT filesystem exists, among other reasons, >> to help DOS detect floppy changes even if there is no change
I did not suggest that UIDE would use this, just said that DOS uses the volume serial to work around "no change line". >> 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... Not sure if this is the same, the change line bit at 40:41 might be updated at other moments than int 13.16 status? In any case, both seem to be polling based, and you might also want to check 40:42. I do not see where you check if a change line is available by looking at 40:xx and if this is generally reliable (and in particular on VirtualBox). > BUT, this AVOIDS "re-entrant" Int 13h calls... I did not suggest to call int 13 in UIDE: Instead, my suggestion is to trigger a floppy cache flush if some software calls int 13.0 or reads a floppy boot sector or calls int 13.16 and gets a "disk changed" reply or "no change line / drive not ready" reply from 13.16. All that can be done by passively monitoring int 13 calls made by DOS or other software to UIDE's int 13. >> 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 As said, I do not suggest that UIDE calls DOS in any way. But I say that DOS tries to be smart about floppy change, thus UIDE can monitor the INT 13 CALLS made BY DOS to trigger a cache flush when DOS "suspects" disk changes, in ADDITION to triggering it when the BIOS knows that the disk changed as per 40:xx monitoring as you already do in UIDE :-) You get a bit less performance (some extra flushes) but also more security (no missed needed flushes). > You should find out exactly what the FreeDOS kernel does My analysis result was that it does not always do a disk reset, although the fact that you have to spin up again after disk changes makes it likely, but that it does use int 13.16 (which you already indirectly tap, using 40:xx monitoring) and that DOS will read the boot sector when it suspects or simply knows about a floppy change... I assume that MS DOS behaves in very similar ways. > Never heard of "boot-sector flush events" I meant "when you NOTICE that somebody reads the floppy boot sector, then flush the floppy cache". Which means that you HOOK int 13, which UIDE does anyway, but do NOT need to make new int 13 calls. >> 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.! Which is interesting, because in SOME aspects, it is supposed to be EASIER to do block device caching because you no longer have to care about hardware properties, geometry or anything similar... > 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... Then the BIOS will scan the bus for you, possibly in an inefficient way, until it finds the Nth (as per the enumeration index passed in SI to int 1a) device of the class in which UIDE is interested. My suggestion was, in particular if you have MORE than one possible class code of interest and MORE than one controller in the system, to scan the PCI address space only ONCE and check all devices that have interesting class codes at the time when you encounter them during that scan. You can gain additional speed here by limiting the scan as described: Only existing bus numbers, no subfunctions of devices that do not exist. And by using port I/O instead of slow BIOS calls :-) >>> 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!! By location I did not mean I/O address base, I meant the PCI bus number and device and subfunction number. If you do not want to use port I/O, you can use for example int 1a.b10a to read dword register 08 which is class, sub-class, interface, revision from high to low byte as shown in RBIL table 00878. Device ID and vendor ID are high and low word of register 00. > 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! I do not know WHAT is wrong with VirtualBox BIOS and or VirtualBox virtual PIIX3 chips, but as said, I see the potential to make the PCI scan of UIDE much faster which would be "instant" instead of "seconds" on most hardware and "seconds" instead of "minutes" worst case. > If they DO NOT have such "long delay" trouble with ICH9 I do not know HOW fast UIDE is in combination with VB ICH9. >> 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. For me this is an indication that PCI BIOS might be open for protected mode compatibility, written in high level languages, rather than being small and fast as a goal. Also, scanning the bus is a rare event and using the I/O port mechanism is easy, well documented and fast, I may conclude that it is recommended and the BIOS functions are more for completeness and where speed is no issue? > The problem here is "VirtualBox". It, AND ONLY IT, needs > to get FIXED in many areas! All else, which has run O.K. Of course you know more about this - was there other hardware so far fow which UIDE does not work or has not perfect (init) speed or stability? I still think that faster code is always an improvement, even if the slowness only really hurts in VirtualBox context. > 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 Just making suggestions for universally faster and more fool-proof UIDE, as I dislike the idea that people have to manually disable floppy caches or tweak their (virtual) hardware to properly load UIDE. Even when the FOOL is the hardware/firmware, it still is good to "deal with it" in generic and automatic ways instead of needing GENIUS users or at least users who can google well or needing extra editions of the operating system for special cases. In my opinion, operating systems should not need manual adaptation to hardware today. Because alas modern BIOSes are bad in declaring UMBs, this is also why I recommend to NOT load JEMMEX by DEFAULT as JEMMEX lacks foolproof detection of foolish PC components and users can not be expected to know about all caveats of their hardware any more... Of course when you know that things work, it is nice to have and enable extra features and JEMMEX and UIDE are certainly very nice drivers then :-) For a similar example, newest Ubuntu disabled the hibernate (suspend to disk) mode by default for computers which contain hardware which is not on a "known to be sane" list... But you can override this after manually triggering hibernation as an experiment: If you find out that everything works after waking up the PC, you enable hibernation, a "power user" thing to do, but better than having hibernation ALWAYS allowed and making users curse if they try to hibernate on broken hardware just to find out that their PC crashes on waking up. I hope you understand my point - JEMMEX even has explicit detection of known-problematic hardware already (just not enough of it) but my ideas for UIDE would give general improvements, without a need to explicitly check whether you run on evil VirtualBox or other evil hardware using a list. 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-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
