Hi!
20-Июл-2004 16:29 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
>> You develop the fnode structures, so should know the better.
BO> No, I just changed them.
...but anyway know better, because already "change them".
>> Thus, may you yourself fix the bugs in lfnapi.c (where used removed
>> f_dmod field instead F_DMOD mask)?
BO> Maybe, it's not very urgent
Of course. But should be done sometime. The earlier - the better.
>> Also, I wish to know: may we remove
>> f_cluster_offset field (and use in fatfs.c:map_cluster() stack variable)?
BO> We may, but we should not as it would seriously hurt file system
BO> performance. f_cluster_offset is a persistent field used to optimize
BO> reads and writes. If you do a forward-lseek to a position (changing
BO> f_offset), then the only relationship you can count on is between
BO> f_cluster and f_cluster_offset, and this enables you to follow the
BO> FAT from f_cluster to the present position, instead of having to follow
BO> it all the way from the beginning of the file.
Ah, yes, I see. As I now understand, f_cluster_offset (not f_offset) is
used to remember file position, whereas f_offset used to pass position into
map_cluster(), instead using parameter of map_cluster().
What you think, if fnode will contain only f_offset (from which also
may be computed the real relative cluster#), and change for f_offset (may
be, except 0) will be performed by map_cluster(), which will receive new
position through parameter (and store into f_offset after storing the
physical cluster number in f_cluster)? (Slightly more and not urgent work to
reduce changes of f_offset outside map_cluster(), but this should reduce
fnode array size).
Also, as induced by Eric:
- may be f_flags joined with f_mode (by placing F_DMOD and other such masks
into bit 2..3 of f_mode)? And/or, f_mode and f_flags should be declared as
UBYTE?
- may/should be `static dmatch Dmatch;' in fcbfns.c moved to stack in the
FcbFindFirstNext() (as in other functions in fcbfns.c)?
- is this bug in dosfns.c:DosGetFree():
/* a passed nc of 0xffff means: skip free; see FatGetDrvData
fcbfns.c */
if (*nc != 0xffff)
*navc = (COUNT) dos_free(dpbp);
? What should be used instead "if (*nc != 0xffff)"? May be, "if (navc)"?
- initdisk.c:LBA_Get_Drive_Parameters(): isn't better to not analyze the
.heads and .sectors fields? Isn't better to not switch to StandardBios
(but use -1ul instead .totalSect) if .totalSectHigh is nonzero (though, it
may be warned anyway)?
>> BO> However, when mirroring an RBIL-dictated structure we should use
>> BO> ULONG (which is FD kernel speak for a 32 bit unsigned integer, I'm not
>> For 32-bit unsigned integers should be used UDWORD type.
BO> Or ULONG or u32 or uint32_t or uint_least32_t or simply "unsigned long".
BO> These structures aren't portable anyway. What's in a name?
Nothing in C/C++ is portable, this is nature of these languages, which
present only machine specific types. But BYTE/WORD/DWORD types are
explicitly developed to ease portability. About uint32_t: good name, but
DWORD (UDWORD) is more traditional. :)
>> PS: Do you see the patch from tom, related to unfreed near fnodes at
>> critical handler?
BO> Yes.
And? For me, it looks as "quick and dirty" hack, may be there is better
ways for "garbage collection" over near fnodes?
-------------------------------------------------------
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_idG21&alloc_id040&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
