> I haven't asked for adding block-device to UIDE, just
> non-BIOS disks support, and I don't need it too _badly_
> since I have none by now.
Non-BIOS disk support for caching already exists in UIDE,
in its "external entry" logic which can be conditionally-
assembled into the driver. UIDE uses its first 48 cache
"unit numbers" for diskettes and hard-disks, and the next
8 cache "unit numbers" for its CD/DVD drives, leaving 200
free cache "unit numbers" for other devices. Each such
device can call UIDE for read/write access using a 48-bit
"logical block number" (LBA), same as a system hard-disk.
Each device also provides UIDE with a "call-back" routine
pointer, which UIDE calls for actual I-O if the requested
data is not in its cache. As noted before, CD/DVD units
within UIDE actually use this "external entry" scheme, so
I know it works fine and could serve other devices, too.
Note that UIDE does not do actual I-O, the device's "call
back" routine does. At present, UIDE has I-O logic only
for SATA/IDE hard-disks, also SATA/IDE/PIO CD/DVD drives.
Users of a non-BIOS device will have to provide their own
"call-back" I-O logic for UIDE. I would consider adding
other "internal" drivers to UIDE only for "major" classes
of I-O devices, e.g. USB/"Firewire", and only if somebody
can provide me a firm and "universally accepted" spec for
the devices. Otherwise, I prefer that an "odd" non-BIOS
unit provides its own I-O logic and uses UIDE's "external
entry" scheme, if caching by UIDE is desired.
Also, Eric Auer wrote:
> ... To give block device access to UIDE disks, you only
> need a partition table parser and a driver similar in
> size to a ramdisk. I would suggest that both is put in
> a driver for UIDE block devices which can be loaded
> separately from UIDE. Alternatively, UIDE could
> provide ASPI access to the found disks, then already
> existing drivers as ASPIDISK can be used for block
> device access :-).
Unless there is some intent by BIOS vendors to "drop" the
Int 13h I-O method for disks/diskettes, accessing Int 13h
devices using "block I-O" methods ought not be necessary.
The Int 13h scheme, especially with its "extended" 48-bit
block numbers, works perfectly well, and a driver such as
Eric suggests would be surperfluous.
Re: UIDE having ASPI support, I am not-interested. ASPI
is a SCSI-like interface scheme, HUGE and "overblown" and
has no business being in drivers intended to be SMALL, as
UIDE is. SCSI has in effect been run out-of-business in
the PC market by less-expensive IDE devices, so it is not
the best use of my time to add ASPI handling in UIDE now.
USB/"Firewire" perhaps, SCSI no.
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
Freedos-user mailing list