Re: [Valgrind-developers] vg_mylibc portability issues

[Nicholas N. <nj...@cs...>]

On Thu, 31 Mar 2005, Julian Seward wrote:

> (*)
>> Hmm... we were just discussing how having all the arch-specific code in
>> one module/directory wasn't really the right thing to do -- that it's
>> better to follow modules boundaries, and possibly have some arch-specific
>> code in each module.
>>
>> Isn't there a similar situation here?  Ie. really the module (or modules)
>> here is our libc replacement or 'utility' module(s) or whatever you want
>> to call it.  In which case we shouldn't have a separate kal/ directory
>> just for the arch-specific things.  Does that make sense?
>
> Uh ... confused.  The above proposal, and what Tom has done, does
> indeed accord with the para marked (*).  It's just that for kal there
> may not be much generic code, and so perhaps kal/any_other_name.c
> might be a bit thin, but in principle it still exists.

In that case, shouldn't the module be called "libc" or "Utility" or 
something, instead of "KAL"?  Perhaps the term "kernel abstraction layer" 
is confusing, since it gives the idea too much weight.  Do we need a 
separate "kernel abstraction layer", or do we just need a libc/utility 
module which happens to have some (possibly many) arch/OS/platform 
specific bits?

I'm not sure if I've explained that any more clearly.

N