DOS386 wrote: > 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. http://p.sf.net/sfu/businessobjects _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
