[Freedos-kernel] re: DEVLOAD / ramdisk troubles - or kernel problems?

[Eric A. <eric@CoLi.Uni-SB.DE>]

Hi, as the KERNEL.dbgdev from fdos.org/kernel works for me in
DOSEmu, I could do some DEVLOAD CD .. problem debugging:

Unfortunately the debug output is very verbose and multi-line, so
I replaced "media_check: no change" by "MC:ok" and replaced
"get_near_f_node" and "got near fnode" by "getfnode" and "got:" below:

> D:\TEMP>cd ..
> MC:ok getfnode: fnp is 0108:0CE0 got: fnp->f_count=1 MC:ok
> truename(..)
> CDS entry: #3 @C430:0108 (2) 'D:\TEMP'
[At this point you get "CHDIR failed" from FreeCOM after DEVLOADing
 the Deskwork RAMDISK or another RAMDISK... Does not happen with
 DEVICE= loaded RAMDISKs or drivers which can be loaded from prompt
 without devload, nor does it happen with usbaspi or aspidisk devload!]
> SUBSTing from: D:\TEMP
> MC:ok getfnode: fnp is 0108:0CE0 got: fnp->f_count=1 MC:ok
> Absolute logical path: "D:\"
> Physical path: "D:\"
> MC:ok getfnode: fnp is 0108:0CE0 got: fnp->f_count=1 MC:ok
> MC:ok getfnode: fnp is 0108:0CE0 got: fnp->f_count=1 MC:ok
> D:\>

Given the code flow in COUNT truename(...) and the (missing) debug
messages before the failure, I think that
> struct dhdr FAR *IsDevice(const char FAR * fname)
has a problem here. But why does that only happen with DEVLOAD?

Other candidates are drNrToLetter() and DosGetCuDir()...
But IsDevice looks like the one: It walks the device chain
starting from nul_dev to check if (the part before the dot of)
the provided filename matches the name of any device.

In the first place, file names like ".", ".." or "\" should
always return "is not a device name" at once without even
walking the device chain.

Second, device chain entries ONLY have names for CHAR devices,
so the "is the name the same as the name of the device?" part
should be SKIPPED for BLOCK devices.

The problem happens in real DOS, in DOSEmu for diskimage drives,
and even in DOSEmu for lredir drives, and it looks like the
kernel is to blame here...


I hope there are still some readers on the kernel list and we
can move the further discussion to that list. A fix should be
quite straightforward: 1. . .. \ are all no device names and
2. dhp->dh_attr should be tested for ATTR_CHAR before comparing
the IsDevice input to dhp->dh_name.

struct dhdr { struct dhdr FAR *dh_next; UWORD dh_attr;
  VOID(*dh_strategy) (void); VOID(*dh_interrupt) (void); UBYTE dh_name[8]; };

By the way, init_device drops devices which either take no memory
(endaddr same as device header location) or are 0 drive block devices.

Eric