>> 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

Reply via email to