>Ok, that sounds reasonable. Cool! >Thanks, Michael, for cutting in for some explanation, I appreciate it! No problem. The active devs have talked a fair amount, internally about this, but I realize that we haven't told anyone. ;-) >So, to summarize what I understand so far: > >Parts of the system wich rely on private commuication APIs will need to >be replaced as sets. With likely the whole system slamazzel being >replaced at once. > >ie: app_server <-> input_server > libroot <-> kernel > app_server <-> kernel > libbe <-> app_server > etc. Pretty much so. In some cases, we have hacked some things, temporarily, to test with, though. >but all the parts which have public APIs will remain binary compat. > >apps <-> libbe >drivers <-> kernel >etc. Yes >So, how far along is libroot? That's gotta be a huge deal. Especially >with making sure it's threadsafe/reentrant, even if you use the GNU one as a >starting point. Not far enough. Libroot is (at least) two pieces - the POSIX stuff and the Kernel stuff. I think that the kernel stuff is further along, but no one is actively doing much with most of the POSIX stuff. A lot of this can/should be a straight port from BSD... >Alan > > >On Tue, Dec 10, 2002 at 03:54:00AM +0100, Axel =?iso-8859-1?q?D=F6rfler ?= >wrote: >> alan@xxxxxxxxxxxxxx (Alan Ellis) wrote: >> > Ahh, but Tracker, and some other apps, use the kernel interface for >> > some >> > things. The MOnitor File Descriptor Problem comes to mind. >> >> Everything the Tracker uses is considered public API for us - more or >> less, of course, because the internal workings might differ. >> But since those APIs are published with the Tracker sources, I think we >> must have them, too. >> >> Adios... >> Axel. >> >> > >