> > Sounds cool. Can you give a two sentence summary of composite?
Composite is a component-based OS similar to a micro-kernel in which policies are implemented as user-level, isolated, components, interconnected with fast IPC. Composite focuses on predictable execution (i.e. bounded-latency for real-time systems), while also scaling that predictability up with an increasing number of features. Now for a bonus run-on sentence that shows what we've been using the system for. A few outrageous (but substantiated) claims: the kernel has no scheduling policy, instead supporting system-wide scheduling in a set of user-level components; the kernel has no locks but maintains consistency while scaling perfectly (we've tested up to 40 cores on 4 sockets); the kernel has no dynamic memory allocator, instead _safely_ relying on user-level to perform that function; system level functionalities (e.g. scheduler, memory mapper) can fail, be rebooted, and reintegrated into the system both predictably, and efficiently (in 10s of microseconds); and a custom web-server is implemented as a system composed of >25 different components. RK fits into our plans as 1. it will give us access to quite a few device drivers, 2. it provides some degree of instant legacy support, 3. we'd like to use our IPC support to provide an efficient rumpctl equivalent, and 4. we'd ideally like to run multiple RKs, each configured with different subsets of overall system functionality. > In the new terminology world order, bmk is the MI+MD "OS" which supports > both hardware and Xen. > I must admit that I haven't had time to follow this whole discussion on the list (the past month has been busy). Is there documentation for the MI+MD in the NWO? > You have ported bmk to "composite", rewriting various bits which were not > suitable for your case. Now you want uses of __thread to suit your system > better. Yes. > If you can get the compiler/linked to generate __tls_get_addr() for TLS > access, AFAIU you can just change bmk_platform_cpu_sched_settls() to do > whatever corresponds to your __tls_get_addr()? > Quite a few of our struggles so far have involved understanding the build system and the system's configuration. We are not NetBSD users (though RK is pushing us in that direction). The higher order bit we'd like to understand -- and I think I know the answer now -- is if there are configuration options with RK and within NetBSD environment to control the implementation of TLS. I'm getting the impression that all of that responsibility is punted out to the host's compiler, and the RK's code uses what is generated by the compiler in the standard way. Thus, aside from bmk's configuration option which only impacts bmk code, there is no broader configuration to change the implementation of TLS. > I'm still not 100% sure of what kind of change you propose to bmk. What's > confusing me is that you've been porting and changing various bits, but now > don't want to change various other bits. > If the problem were only in bmk, then we'd have no issue. We can modify that without significant impact on the rest of the system. However, we'd like like to avoid modifying the rest of the system to the greatest extent possible. What triggered this email was seeing that the NetBSD libc uses __thread for errno (which is perfectly logical). We can also "fix" that reference, but before making broader changes outside of the platform-specific code, we wanted to see if anyone knew of any other option. Best, Gabe
