[klibc] emu86 in klibc
H. Peter Anvin
hpa at zytor.com
Mon Mar 14 07:25:54 PST 2005
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
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
> 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
More information about the klibc