Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28
On Mon, 22 Mar 2004, tom ehlert wrote: > AVB> (BTW, is "protection" > AVB> from wrapping HMA pointer into IVT by replacing wrapping into start of HMA > AVB> worth of code?) > a working kernel is worth a lot of code (even if you don't see the > reason immediately) > > HANDS OFF THE KERNEL, please. in the end it was just easier to remove add_far() and use buffer = adjust_far(buffer + offset). The only users are dsk.c and fatfs.c, where this is safe as long as you normalize the pointer before the loop. Which it was in fatfs.c but not in dsk.c. For the HMA. Yes, hands off: we do often read things (indirectly) into the HMA, there are BUFFERs there for instance. Maybe, just maybe, we're safe now with removing HMA logic from adjust_far() -- but it's way too easy to break this and will lead to bugs that are hard to solve. The current CVS kernel now has a 450 bytes smaller HMA_TEXT than ke2033 :) Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28
Hi! 22-Мар-2004 17:57 [EMAIL PROTECTED] (tom ehlert) wrote to "Arkady V.Belousov" <[EMAIL PROTECTED]>: AVB>> Then rename "add_far" into "normalize_ptr" and remove misleading. te> noone is going to rename functions because you don't like the names. "I, as typical programmer" :) say, that there is misleading (which causes wrong understanding when reading source). In other "add_far" is _not_ "don't liked" me. AVB>> Also, I may offer next code to always perform normalization: te> It's there for some specific purpose. Bart does better - he removes add_far and reuses adjust_far. :) --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28
Hello Arkady, AVB> Then rename "add_far" into "normalize_ptr" and remove misleading. noone is going to rename functions because you don't like the names. AVB> Also, AVB> I may offer next code to always perform normalization: It's there for some specific purpose. AVB> (BTW, is "protection" AVB> from wrapping HMA pointer into IVT by replacing wrapping into start of HMA AVB> worth of code?) a working kernel is worth a lot of code (even if you don't see the reason immediately) HANDS OFF THE KERNEL, please. tom --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28
Hi!
22-Мар-2004 14:23 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO> add_far is only used at a few select places where we want to have the
BO> offset part as low as possible. Nothing to do with structures but
BO> everything to do with potentially large file reads, with "read chunk,
BO> update pointer" loops.
BO> Quite possibly Arkady's approach minimizing normalizations has merit but
BO> then each add_far caller needs to be checked if it needs to manually
BO> normalize the pointer afterwards.
Then rename "add_far" into "normalize_ptr" and remove misleading. Also,
I may offer next code to always perform normalization: (BTW, is "protection"
from wrapping HMA pointer into IVT by replacing wrapping into start of HMA
worth of code?)
void FAR *normalize_ptr (void FAR *fp, unsigned add)
{
unsigned ofs = add + FP_OFF (fp);
seg/*_t*/ s = FP_SEG (fp);
if (ofs < FP_OFF (fp))/* arithmetic overflow? */
s += 0x1000;/* add carry */
return MK_FP ((ofs >> 4) + s, 0xF & ofs);
}
BO> But for now, because it's not called very often, the time it takes is very
BO> small in comparison with the BIOS calls following, and normalization doesn't
BO> hurt, I haven't changed it.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
___
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28
On Mon, 22 Mar 2004, Eric Auer wrote: > Hi, about add_far() pointer normalization: I think it would be > better to normalize earlier. If you have a pointer, you normally > have a pointer to a STRUCTURE. If the end of the structure ends > up with an offset > 0x then having the POINTER normalized is > not enough. So how do you check the SIZE of the structure for > which you normalize the pointer? Or do you just have an hardcoded > constant "maximum structure size" for structures for which the > add_far function can be used? add_far is only used at a few select places where we want to have the offset part as low as possible. Nothing to do with structures but everything to do with potentially large file reads, with "read chunk, update pointer" loops. Quite possibly Arkady's approach minimizing normalizations has merit but then each add_far caller needs to be checked if it needs to manually normalize the pointer afterwards. But for now, because it's not called very often, the time it takes is very small in comparison with the BIOS calls following, and normalization doesn't hurt, I haven't changed it. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Re: kernel/kernel fatfs.c,1.52,1.53 proto.h,1.50,1.51 memmgr.c,1.27,1.28
Hi, about add_far() pointer normalization: I think it would be better to normalize earlier. If you have a pointer, you normally have a pointer to a STRUCTURE. If the end of the structure ends up with an offset > 0x then having the POINTER normalized is not enough. So how do you check the SIZE of the structure for which you normalize the pointer? Or do you just have an hardcoded constant "maximum structure size" for structures for which the add_far function can be used? Eric. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
