On 9 April 2015 at 14:26, Antti Kantee <[email protected]> wrote: > > What is the benefit of re-adding the laying violations that just have been > fixed? (well, mostly fixed, still some left in platform/xen) > > The duplicated code is very minimal: ~6 str/mem routines and eventually > atomic CAS (MD). I'd rather just copypaste those than again make it > impossible to reason about which bits go where and what can get accidentally > used. The routines probably even could be just built from src/common like > libkern, objcopied into the correct namespace, and be done with it. But > used implicitly from libc without any guarantees of what's going to happen > when they're called or making it possible to #include anything form userland > namespace in layers <5: no.
No, they cant include anything from userland namespace, they have a limited minimal set of headers so they cant include anything else. But as even the compiler is adding these libc functions when it feels like it (eg on arm), it is not very easy to not have them. And even if you put them in core, platform may need them, so you have a mutual dependency there too. > #1-#5 are all wrapped into the libc that is produced >> >> to link applications against. > > > That's a build system detail which is a trade-off between flexibility and > simplicity. It might be a genius approach or a disaster. I don't yet know > which one it is, but definitely will keep an open mind towards it. Oh its definitely not a disaster.
