Paulo Marques schrieb: [...]It seems to me that x86 emulation in the kernel is the way to go because:
[...]
3 - it's always there and can be executed at *any* time: booting, returning from suspend, etc. Also it would allow the VESA framebuffer driver to change graphics mode at any time (for instance).
OK, and what would force you to do the above in the kernel? If the code lives in initramfs, it can be called very early, too.
Not as early, anyway, and it would make the setup for the initramfs (at boot) and the resume much more complex.
The line line between what should go in the kernel and what should live in user space as always been a fuzzy one, and it's been moving in a dangerous direction lately, IMHO.
In my opinion there are 3 major factors for something to go into the kernel:
1 - resource management between user space processes (this includes locking, etc.)
2 - performance
3 - hardware abstraction
This latest point is being more and more ignored by kernel developers.
In a previous thread about using the frame buffer accelerated operations from user space, Jammes Simmons wrote:
"You can mmap the mmio address space and program the registers yourself."
and just 3 minutes later, Geert Uytterhoeven wrote too:
"mmap() the MMIO registers to userspace, and program the acceleration engine from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and Mach64) does."
This is a even more horrid example, because the drivers in the kernel already have the code to do the accelerated functions, and we just don't have the interface for them to be called from user space.
It is another example of "this can be done from user space, so why put it in the kernel". To have a consistent interface for similar operations without having to know the underlying hardware, perhaps?
At least Helge Hafting wrote on the same thread:
"I believe you also can write a small driver that connects to the framebuffer the same way the fbconsole does. It could then export all the operations so userspace actually can call them."
Which seemed a much better solution to me.
And how many competing implementations of video helpers/emulation code do we have now?
- scitechsoft emu - linuxbios emu
I think these two are the same (or at least that is what Li-Ta Lo is working on)
- etc. (I surely forgot some)
This one I've never heard of :)
Anyway, as it happens with anything in the kernel, several different solutions for the same problem get selected by "natural" selection, and evolve "genetically" into the final version.
-- Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
