|
From: Julian S. <js...@ac...> - 2005-03-30 16:15:23
|
On Wednesday 30 March 2005 16:15, Nicholas Nethercote wrote: > On Wed, 30 Mar 2005, Tom Hughes wrote: > >> Instead, it would be better to put the Kal module/subsystem > >> in its own directory, kal, and put all the arch/os specific bits > >> just for Kal in there: > >> > >> kal/pub_core_kal.h -- services exported from kal; core but not > >> tools may use these > >> kal/pub_tool_kal.h -- services exported from kal; both core and > >> tools may use these > > > > How are we going to decide what is and isn't exported? Do we make > > everything core only to start with and move it to the tool header > > if a tool needs it? or make everything available to tools unless > > we have some reason to believe it can only work in the core? > > The former; the tool should see as little as possible. That's how it has > been done in core.h and tool.h. Yup. Tools may see only a subset of what the core may see. So (as is the case with Tom's patch) tool.h exports as little as possible, and as much as possible (here, everything) is in core.h. The only change then needed is that core.h #includes tool.h so as to guarantee the subset/superset relation. > >> kal/kal-x86-linux.c -- x86-linux specific implementation > >> kal/kal-amd64-linux.c -- amd64-linux specific implementation > >> kal/any_other_name.c -- generic implementation > > > > I'm not sure you can have a generic implementation of anything in the > > kernel abstraction layer ;-) > > I guess it depends on whether you keep as a separate layer, as you did in > the patch, or fold that into KAL. I presume you're referring to what to do about VG_(strlen) et al? I think those could go in a different module as they are all pretty harmless. > If nothing else, the kal_* functions may as well be called > VG_(getpid)(), etc, rather than either changing all the callers or > having a file full of stub functions. No ... I prefer to keep the kal_ prefix. It isn't intrusive and it avoids the burden of having to remember whether VG_(obscure_foo) is a Kal function or not. In the same way that all the POSIX pthreads functions and types are trivially identifiable from their names. J |