Re: Unit testing kexts
Re: Unit testing kexts
- Subject: Re: Unit testing kexts
- From: Stan Sieler <email@hidden>
- Date: Fri, 26 Aug 2016 13:21:37 -0700
Re:
> space application and performing our tests there. Over time, as we have increased our code coverage of the unit tests, we’re noticing a pretty strong upward trend of the number of compiler conditionals required to support cross-compiling between a kext and a user-space app. For example:
...
#ifdef UNIT_TEST
> str = (char*) malloc(sz);
> #else
> str = (char*) OSMalloc(sz, gOSMallocTag);
> #endif
...
> Suffice it to say, we’re wondering if there’s a better way. Ideally, we would like to unit test the code that’s actually running in production. These compiler-level conditionals force us to essentially maintain two versions of our code. Worse than that, the unit tested version is not the production version.
The following is not a kext/Mac/platform-specific suggestion, but...
When I encounter this, I move the code into a (hopefully small) module
of routines that tend to vary (or not exist) from platform to platform
and then use "cover functions" to access them.
E.g., str = ss_malloc (sz);
...which gets implemented as one of the two different malloc's you show.
So, my "ss_read" and "ss_seek", for example, take a guaranteed int64_t #bytes,
and returns a guaranteed int64_t result ... no worrying about int vs.
size_t vs. ssize_t vs. offset_t, for example. And, no worrying about
whether I need to call read or read64 (or lseek / lseek64), which I used
to have to worry about on some platforms.
(Inspired, years ago, by Terry Winograd's "Breaking The Complexity Barrier, Again"
article :)
Stan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden