Bart Oldeman wrote:
> thanks for that link -- this program indeed helps quite a bit for
> troubleshooting.
I was sure you would like it!
> blk_dev.dh_name[0] is the number of *builtin* (supplied by dsk.c) block
> devices. The global number is stored in LoL->nblkdev.
Now I see! Sorry about my confusion and thanks for your explanation.
> the dpb_unit is the drive letter - 'A'
> the dpb_sub_unit is the relative drive letter within the device driver,
> so
> '0' is correct for all device drivers which supply only 1 drive (unless
> I missed something).
Well, although I think you're right in principle (since there's no point
in having two identical fields in one structure), there is some
confision about the dpb_sub_unit field. In both MS-DOS 7.1 and PC-DOS
7.1, dpb_unit = dpb_sub_unit for both built-in (C and D) and installable
drives (E, F, G) - I tested it with DUMPDOS! Here's what the definitive
source, the IBM PC-DOS 7 Technical Reference Manual says on the DPB
fields (page 361):
DPB structure:
dpb STRUC
dpb_drive DB ? ; Logical drive # assoc with DPB (A=0,B=1,...)
dpb_UNIT DB ? ; Driver unit number of DPB
dpb_sector_size DW ? ; Size of physical sector in bytes
dpb_cluster_mask DB ? ; Sectors/cluster - 1
dpb_cluster_shift DB ? ; Log2 of sectors/cluster
dpb_first_FAT DW ? ; Starting record of FATs
dpb_FAT_count DB ? ; Number of FATs for this drive
dpb_root_entries DW ? ; Number of directory entries
dpb_first_sector DW ? ; First sector of first cluster
dpb_max_cluster DW ? ; Number of clusters on drive + 1
dpb_FAT_size DW ? ; Number of records occupied by FAT
dpb_dir_sector DW ? ; Starting record of directory
dpb_driver_addr DD ? ; Pointer to driver
dpb_media DB ? ; Media byte
dpb_first_access DB ? ; This is initialized to -1 to force a media
; check the first time this DPB is used
dpb_next_dpb DD ? ; Pointer to next Drive parameter block
dpb_next_free DW ? ; Cluster # of last allocated cluster
dpb_free_cnt DW ? ; Count of free clusters, -1 if unknown
dpb ENDS
Now, what does "Driver unit number of DPB" (dpb_UNIT) mean? It's not
clear! True, Ralf Brown clearly says that it is "unit number *within*
device driver" but this is starting from DOS 2.0. For DOS 1.x it was
quite different, and maybe this is the root of the confusion?! Maybe
some code in the drivers checks this field?! Even though it may really
be a SUB-unit number, then why it isn't so in MS-DOS 7.1 and PC-DOS
7.1?! It's even more strange that due to some bug in PC-DOS 7.1, the
unit (drive) number for my drive G: (the second unit in the ATA driver)
is... 53h instead of 6, and this drive doesn't work with this kernel!
> dsk.c is the kernel's builtin disk device driver so here the sub unit
> value is indeed nonzero.
Yes, at least that is certain...
> What you might want to check though is the behaviour with kernel 2029. I
> reorganized this code for kernel 2030 to support FILESHIGH and so on but
> broke something (what we're looking at now).
I did this and apart from the fact that HIRAM.EXE crashes it and there's
no DOSDATA command, it behaves the same way as 2030. (Build 2029 doesn't
show the entries for the installable device drivers in "MEM /C" either,
so we really have big progress in many areas now! ;-)
Maybe this bpb_sub_unit thing is a false track and there is nothing
wrong with the difference in it between MS/PC-DOS and FreeDOS. But the
comparison between builds 2029 and the current CVS build shows identical
behaviour in this area. So it's logical to conclude that the bug (if we
really have a kernel bug here) existed in 2029 too. What a pity that I
didn't dare to do these tests earlier!
One more note. Many times the directories shown for the non-working
drives F: and G: (with high load enabled) are... some subdirectories of
drive C: (for both 2029 and current kernels)! Maybe some disk *buffers*
are messing up here?!
Lucho
==^================================================================
This email was sent to: [EMAIL PROTECTED]
EASY UNSUBSCRIBE click here: http://topica.com/u/?b1ddyi.b3hwCs.YXJjaGl2
Or send an email to: [EMAIL PROTECTED]
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
==^================================================================
