Jack, kernel experts,

> On REAL (old) PC hardware, the existence of floppy disk changelines
> is not guaranteed; even if the line is present AND properly connected
> it MIGHT be flaky or not work at all; or the BIOS might not update
> the bits you expect. MS-DOS (and, I presume, good DOS clones as well)
> will use alternate means and kluges to check for media change in the
> absence of a (credible) change line. Your DOS drivers could have been
> relying on DOS for checking media change, not on the BIOS or direct
> HW interrogation in the 1st place!

When DOS detects an unreliable floppy change line hardware,
it should use the floppy label / serial / similar to detect
changes in software. Maybe FreeDOS does this, maybe not? Is
a change in label / ID always a trigger for a change event,
or only in context of having detected hardware reliability
troubles before?

> Offering the user an option to switch diskette caching off is much
> better. As you are aware, SMARTDRV allows a user to select...

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? Depending on other factors, even flushing the caches
for all drives or all floppies would still be better than a
situation where the cache still contains data from old disks
which are no longer inserted in the drives: Rather be SAFE,
have some performance loss (due to extra flushes, less cache
efficiency is reached and the flush itself also takes time)
than SORRY (data loss due to mismatch in cache / real data).

If the kernel issues eg. int 13.0 after detecting a floppy
change - which it should be able to do even if the change
line is unreliable - and UIDE2 reacts to that with a flush,
DOS can take care of the reliability while UIDE2 still only
has to care about int 13 calls :-) Also this makes it safer
to use UIDE2, as is does not need manual /N safety options.

>> -- UIDE2 has only 16 spare bytes before it goes back over a 7K
>> .SYS file!   But, I shall find a way!

Thanks :-) By the way, any chance to work around the VirtualBox
huge-delay problem? Apart from configuring VirtualBox to use a
different virtual chipset, I mean. It seems that UIDE2 code, in
particular I_ScnC, I_PCIC and I_PCID uses BIOS calls (not fast?
raw I/O) to scan ALL possible bus/device/function numbers, thus
ignoring the "last used bus number" returned by int 1a.b101.0?

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.

Just some ideas, of course, but might also help to make UIDE2
more robust with other flawed "hardware" or BIOS versions :-)

Note that for example PCISLEEP only uses raw I/O in getpci and
skips looping over functions if function 0 of a bus and device
number pair return "PCI ID -1". So you scan only 1 out of 8 in
such cases. Each bus has 32 device numbers to scan. Also, often
you have far less than 256 bus numbers in use, saves much time.

By the way, PCISLEEP only supports the "newer" mechanism 1, the
"ancient" mechanism 2 for I/O is not supported but rarely used.
See also: http://wiki.osdev.org/PCI and also note that SYSLINUX
3.05 calls mechanism #2 a "hideous old hack" yet supports it:
http://www.syslinux.org/old/history.php As you see in PCISLEEP
source code, mechanism #1 is easy and compact to implement :-)

Regards, Eric

PS: The UIDE issue is described in Ulrich's wiki page which also
is a good GENERAL "how to install FreeDOS 1.1 on empty harddisk"
document :-) I would also suggest to make /NOHI the KEYB default!
The KEYB thing might be due to rawer-than-EMS-style UMB attempts?

> http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_8

> http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_9

PPS: Heat-wise (VirtualBox Chapter 7) I suggest to add FDAPM to
one of the default driver sets in FreeDOS 1.1 config / autoexec.

> http://sourceforge.net/apps/mediawiki/freedos/index.php?title=VirtualBox_-_Chapter_7#Possible_Solutions:_2._Use_DOS_Power_Management

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