Hi! >> You could write such a driver but you have to remember that "DOS >> block device" already implies FAT anyway. > > This implication is a part of the problem I'm talking about. DOS (rather, > the DOS device loader) shouldn't assume that just FAT exists (it also > shouldn't discard non-FAT partitions from the MBR) but instead it should > first provide any filesystem to all loaded redirectors so if one of the > redirectors finds a non-FAT partition with a supported filesystem it could > add this block device to it's devices.
You could indeed simplify some drivers a bit by letting them use knowledge from the partition table parser of the kernel (initdisk.c) or the disk access code (which onlly does int13 CHS and LBA calls anyway). Not that it would make a big difference, though... >> In the ATAPI CD/DVD case, that interface is some >> int2f and some "DOS character device" interface, nothing "block". > > Why do CD/DVD drivers need to have a DOS device visible to the DOS kernel > at all, then? Actually, they don't. Pretending that it's a character > device (which CD-ROMs usually aren't) is a hack... Character devices can be found by their name and can be controlled via IOCTL... In addition, because you pass the device name as command line option to CDEX, this way is slightly more end user friendly than int2f handlers, in particular if you have more than 1 CDROM driver loaded. But as you say, it does not make a real difference :-). > If MS-DOS (3.x) had support for linking > the redirector interface with block devices, CD/DVD drivers would probably > be written as DOS block devices, reporting impossible values when asked > for a (FAT-specific) BPB. While both the DOS block device interface and the CDROM driver interface are relatively small, they are not as similar as you might assume. The latter has various CD audio related calls, for example. > The major problem seems that the redirector interface was designed for > network redirectors, not for any kind of local non-FAT filesystem driver. You could indeed design some interface which gives block based easy access to non-FAT int13 devices, possibly duplicating some involved small parts of the kernel... Then you could evaluate how many and which DOS drivers for other filesystems would use it, and then based on the outcome, some implementation of that interface can be put directly into the kernel. As said - my guess is that you would only simplify life for non-FAT drivers a bit. On the other hand, you might only complicate the kernel a bit either, so the pro and contra of your suggestion are both relatively small...? Eric ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
