|
From: Julian S. <js...@ac...> - 2005-03-29 16:39:21
|
On Tuesday 29 March 2005 14:53, Tom Hughes wrote:
> A number of routines in vg_mylibc.c are simple wrappers around
> system calls which means that they are OS and/or platform specific
> and shouldn't be in the core code. In fact a number of them are
> currently disabled on amd64 because the system call they need to
> make is different there to x86-linux.
>
> One obvious answer would be to move them into the linux or
> x86-linux/amd64-linux directories as appropriate. They would
> to keep the VG_() designation though as it would be OS dependent
> whether they needed to be in the OS or platform directory and
> therefore have a VGO_() or VGP() designation.
>
> The only one that have been moved so far seems to be mmap which
> was done by creating a VGP_DO_MMAP macro although that is also
> used in a number of other places.
>
> Does anybody have any opinions on how best to deal with with
> this? and is anybody already working on resolving this or is
> it clear for me to take a look at it?
It certainly needs cleaning up. I mused on this a while back.
What I want to happen is for a Kernel-services Abstraction Layer
(Kal) to appear. In the same way that Moz has NPSR, OOo has
SAL, etc. Kal will provide services like mmap etc whilst hiding
the details of how the call is done on different platforms. Of
course Kal will be far simpler than NPSR, SAL, etc, but the idea
is the same.
So that's something worth looking into. I plan to do this myself
anyway at some stage, but if you want to look into it, please do.
A related problem is that in various places there are
direct use of syscalls (viz, do_syscallN(args)). This is
at odds with portability, and those should be replaced with
calls to the Kal interface. My intention is that, apart from
the syscall wrappers, doing syscalls directly is banned: all
requests for kernel services must go through Kal.
Another thing is that I don't think the current division of the
source base into generic stuff, x86 stuff, amd64 stuff, etc, is
necessarily the best top-level structure. Although it does
separate out the plat-dependent stuff, it obscures module
boundaries -- which imo are the most important thing to have
a clear picture of, from a maintenance/understanding point of view.
This is because, for example, to build such a Kal module, you
would have some generic stuff in one set of dirs/files, but also
bits of Kal scattered in the x86-linux, amd64-linux, etc, trees.
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
kal/any_other_name.h -- private header files for use only within
kal/
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 hope to diffuse the code base towards this kind of module structure
on an ongoing basis. An auxiliary idea is then to have a perl script
which runs at build time, which examines #include statements and
thereby mechanically enforces the requirement that only the publically
visible interfaces of each module are used outside of that module.
J
|