|
From: Julian S. <js...@ac...> - 2005-03-30 15:19:13
|
> > Tom, perhaps you could generate some patches and post them to the list > > to see how they turn out. It will be interesting to see how much libc > > stuff is platform-specific. > > Attached is a first cut at a kernel abstraction layer. It removes > most of the direct system calls from the coregrind directory and > moves them into KAL routines. As a side effect it implements the > missing mylibc functionality for amd64. Tom That looks like an excellent start. Does it compile/build on both x86 and amd64? > I've made a start on removing VKI types from the KAL interface as > any abstraction layer will need to be independent of the types used > to communicate with the kernel. Many routines still use VKI types > in their interface however. I guess kal basically implements a tiny subset of libc functionality. We need to consider a way to deal with returning error values. Currently those functions return -1 if there's a problem, but: * that precludes them returning -1 as a legitimate return value * having -1 as the only return value may not give enough detail for the caller to diagnose an error return and take appropriate action Not sure how to fix this. We could copy the libc madness and have an errno which gets set with a value indicating the problem. Or we could give all kal functions an Int* first parameter into which an error value is written if there is an error. In either case we'd need an kal-specific enum holding error codes (KAL_EINVAL, KAL_EBADF, etc), and, for each target, a function which converts kernel return values for the target into KAL_E* values. Comments? > I think we should just use the libc API for this, if not the system > glibc. Yes. The above suggestion effectively enshrines that, modulo perhaps sidestepping the errno uglyness for returning error codes. > Would uclibc be a good basis (http://www.uclibc.org/)? It would > get us out of the business of maintaining a C library as well. Currently we only use a tiny subset of the libc functionality. Its behaviour is well defined and understood and we haven't had a problem maintaining it. If we were going to use most/all of libc then uclibc might be a good choice. But considering that we don't have a maintenance problem, using someone else's libc just imports another load of assumptions and constraints to work around, and I don't want that. Besides, it would then constrain us to platforms on which uclibc works. J |