Hi, I reduced the 500 line mail to 140 lines now... enjoy. Eric.
lfn_inode: l_diroff offset could be an UWORD slot number, smaller
dmatch dm_size is LONG but should be ULONG
and dm_flags is not currently used. Note that the offsets in the
structure are fixed, so dm_flags is to be replaced by a reserved field.
It should be documented in comments that dmatch is "findfirst/findnext
data structure".
Of f_node f_flags, F_DMOD, F_DDIR and F_DDATE are used, so at other
places, f_dmod should be replaced by F_DMOD in appropriate manner
("other places" is probably only the lfn hooking API?).
Can f_node f_count be turned into UBYTE? It is incremented in get_f_node
and set to 1 or 0 or decremented at various other places.
You can turn f_mode and f_flags into UBYTE. With a little more work,
they can even be merged (flags: 3 bits used, mode: values 0..3 used).
That and "UBYTE f_count" saves 3-4 bytes (of 54/60 for FAT16/32 kernel)
per f_node in RAM.
Note that the non-f_node file open mode does use almost all 16 bits!
Maybe one can use the SFT open mode to replace f_mode completely?
Or would that impact performance too much?
The "relative cluster number within file", f_node f_cluster_offset,
can at most have 23 bits used (for 4 GB files). By the way, normal
cluster numbers are at most 28 bits, rounded up to 32 bits.
That would allow an obscure reduction of f_node size for FAT32
kernel by 1-2 extra bytes, but is probably slow and bug-prone.
There is FreeDOS specific O_LEGACY, but O_LARGEFILE does not seem to
be supported yet (that flag removes the 2 GB size limit from seek
and write operations).
Other FreeDOS specific file open flags are O_OPEN, O_CREAT and O_TRUNC.
Maybe one could condense those a bit if free bits are needed for
something else instead.
The dos_open O_EXECCASE flag (mode 3 after O_ACCMODE bitmask) would
cause "case preservation for exec / redirector", seems to be TODO.
Similar for "flags & 7 == 4", which is a variant of readonly open mode,
but avoids modifying the file access time.
The O_SYNC (commit all writes at once) and O_NOCRIT (do not use int 23
(really? or int 24?)) seem to be TODO, too. Should be quite "doable".
In sft, sft_size and sft_posit should be ULONG, not LONG.
In addition, SftSeek/remote_lseek/dos_lseek should honor O_LARGEFILE.
Notice that this means dos_lseek return type change and foffset
argument type change. Because DE_INVLDFUNC and DE_INVLDHNDL can be
returned, you must either limit file size to 4 GB - 256 bytes or
pass separate return values for errors and offsets.
The xstructs.h file should not be #included in non-FAT32 kernels.
The DWORD fields there should be ULONG/CLUSTER, but take care to
fix "< 0" or "== -1" type comparisons (your compiler should warn...).
Having no xstructs.h helps to keep FAT16 kernels "FAT32 free".
DosGetFree (FatGetDrvData int 21.1c/21.36) can crash, maybe because of
a NULL navc pointer. I wonder if it is really desirable that the
current implementation fakes bigger cluster sizes to allow cluster
counts below 64k (DosGetFree is an interface for FAT16 originally).
Maybe saturation would be better. How do other DOSes handle this?
Note that *nc and *navc already are clipped ntotal and nfree values.
For drives beyond lastdrive, get_cds result protects from crashes,
but in between, access to unformatted disks returns nonsense for
int 21.36 and even crashes while trying to do critical error dialog
for int 21.1c - probably some 0:xx data or stack got overwritten.
Related functions: media_check, rqblockio, flush_buffers, bpb_to_dpb,
dskxfer. Maybe the DF_NOACCESS should be modified to avoid critical
error dialog and return "unknown media type" dirrectly. See also:
getbpb function, RWzero "wrapper" for LBA_Transfer. rqblockio also
contains an ASPI/USB kludge for C_BLDBPB.
This should need no typecast: dmp->dm_size = (LONG) SearchDir.dir_size;
...
The DosLockUnlock function and remote_lock_unlock and share_lock_unlock
should use ULONG, not LONG, for pos and len. You have to do something
about "s->sft_shroff < 0" then I think.
The following 2 comments are wrong:
/* dos_getfsize for the file time */
/* dos_setfsize for the file time */
The dos_setfsize should use ULONG for size, as does dos_getfsize.
The lfn_setup_inode should use CLUSTER for dirstart, as dir_init_fnode.
(And the int 21.7403 handler should typecast to CLUSTER, not ULONG).
DynAlloc does not really need that typecast to ULONG to compare.
Should other places apart from DosRWSft update current_filepos, too?
For better list-of-list compatibility. The "Globally referenced
variables" should have a comment telling that they "are" List of
Lists from some offset on.
LBA_Get_Drive_Parameters should NOT disable LBA access if heads or
sectors are > 64k or if totalSectHigh is nonzero. Instead, only a
warning should be shown and totalSect* should be clipped. Using CHS
is definitely worse for huge drives than LBA.
Note that geometry taken from LBA BIOS is not used anyway, only the
size information is used. For CHS, the CHS BIOS geometry is used.
At several places, "ULONG / value" and "ULONG % value" could be
explicitly marked as "ULONG / UWORD" and "ULONG % UWORD" type,
to allow compiler optimizations (32:32->32 bits is more complex
on 8086 than 32:16->32 bits). After a long search, I found that
the kernel itself never divides things by more than 65535.
If your compiler allows custom "32bit division" code to be used,
you can also special-case division (and modulo) by 512, because
this often happens (without being "hardcodeable": ultimately we
want to remove all fixed SEC_SIZE values) and - on a real 808x
- a division can be quite slow. We have LDIVMODU and LMULU:
dx:ax = dx:ax / cx:bx, cx:bx = dx:ax % cx:bx, dx:ax = dx:ax * cx:bx
LBA_Transfer should call the appropriate int 2f.xx function before
calling play_dj - or play_dj should call it itself: This allows
GUIs to return "okay, notified, please suppress DJ text message".
There also is int 1e stuff, disk reset, track wrap avoidance and
DMA wrap avoidance. For the latter two, I recommend:
If buffer is exactly aligned, transfer limit should probably be
64k, not 64k - 1 sector. Track wrap protection and DMA wrap
protection should be turned off (maybe add a SYS CONFIG variable!)
for harddisks. There is also UMB avoidance: If a buffer is in
UMB or HMA, all access is copied through the low RAM disk transfer
buffer (which is only 1 sector big). Probably required, but should
be mentioned in kernel docs (<-> DEVICEHIGH/LOADHIGH).
If the wrap checks would be done by int 13 handler (with int 2f.13
control interface as in FDSHIELD), not only DOS access but also
direct disk access would be protected, plus you gain disk change
detection reliability. Maybe make that a compile time option.
[Grrrr... know your mailx tilde escapes! ~r, not ~c...!]
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
