On 19/02/15 00:02, Justin Cormack wrote: >> One suggestion: don't use or depend on libc naming schemes. The reason >> I explicitly didn't provide string.h etc. in -baremetal was to avoid the >> -xen tailspin where modules both provide for libc and depend on it (or >> would that be an immelmann?). >> >> Two weeks ago I started work on the interfaces between the MI bits (e.g. >> scheduler and lwp.c) and the platform (e.g. -xen and -baremetal). >> However, I noticed that I also need some partial type system in that >> interface (e.g. size_t), and couldn't quite make up my mind on how to do >> it. Then came the fosdem plague. > > The problem with not using the standard names is that the code already > exists and calls the standard functions. Plus interfaces as you say > need size_t and things. My plan is to link the libc with librumpuser > to produce a combined library so nothing leaks, or to use objcopy to > rename them after compiling, whichever is easier.
So for -posix, provide the standard, already-called functions in terms of the underlying interface. That way there's no need to hack up the existing code, but we still get an explicitly codified interface instead of it being some subset of libc with some unclear amount of assumptions. Furthermore, if we unify some bits of librumpuser in the future, I'd rather have them run on top of an interface of our defining instead of emulating the libc ones everywhere. ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
