|
From: Julian S. <js...@ac...> - 2005-03-30 16:36:57
|
> > That looks like an excellent start. Does it compile/build on both > > x86 and amd64? > > It does now - the version I sent before had a few minor issues > on x86 but I've just fixed them. Cool. > Yep, the whole question of error codes was another thing that was > a bit thorny when I was doing it. I mostly tried to push the is_kerror > tests down into KAL but some of them are still outside which is wrong. I entirely agree. > I agree that we really want out of band error reporting, which means > either reserving the return value for the error and returning any > other values through reference arguments, or adding an error argument > to each routine, or using a global. A global (errno) is ugly and gives problems should we ever get into a genuinely multithreaded environment. Returning the normal return as a ref param is a bit cumbersome, because often we want to see the return value but ignore the error value (eg, kal_getpid; that cannot fail). Hence it seems to me the cleanest solution is for the error value to be a var parameter which we mandate always to be the first param. We allow it to be NULL. Then we can conveniently do pid = VG_(kal_getpid)(NULL); which is not excessively intrusive. > > 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. > > Sounds about right. Error codes presumably have to be in the tool > visible header, along with any structures that tool visible functions > want to use in their interface. Sounds exactly right. > >> 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. > > Well the other thing that I did for several routines was to use > a simpler interface that didn't rely on kernel structures, so for > example gettimeofday just returns a ULong and nanosleep takes a > ULong rather than faffing about with a structure. That I like -- it sounds like a good thing. In fact, we need to not have any kernel types, structs or consts in the kal interface. > Likewise for getrlimit/setrlimit which were the other ones where I > made an attempt to remove VKI types from the interface. Yup. I presume you'll have an updated patch after a bit more iteration? J |