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

Reply via email to