[klibc] emu86 in klibc

[H. Peter Anvin]

Jon Smirl wrote:
> 
> How about as another library in the klibc tree? Right now there is no
> central point for emu86,  there are at least four development trees.
> klibc is slated to go into the kernel sooner or later too, right?
> emu/vm86 is used in general for running ROMs on cards, it is not video
> specific.
> 

Well, at this point that would effectively mean that I would take over 
maintenance of emu86, and I don't think I have the time to do that at 
this time.

> With the new model of moving pieces of device drivers to user space
> we're missing a place in the kernel tree to keep these programs. What
> is the plan for this? The video drivers are going to have two tiny
> helpers: post the ROM, parse EDID and build the mode list. Without
> these the driver isn't going to work very well. These helpers are
> target to run in early user space during boot.

This kind of stuff could certainly be done in early userspace (and yes, 
that would justify adding that support to a merged klibc.)  However, I'd 
rather do the push for merging first, unless it starts getting used already.

Doing another library is probably the easiest.  In theory, one could add 
infrastructure for more than one shared library, too (it would have to 
be explicitly mmapped, though, the kernel will only load exactly two 
executables) but I think that would be the route of last resort -- if 
there are genuine consumers, it can go in the same binary as far as I'm 
concerned.

	-hpa