Re: [RFC] Reliable video POSTing on resume

[Paulo Marques <pmarques-TSnNRl9vlf1Wk0Htik3J/w@public.gmane.org>]

Carl-Daniel Hailfinger wrote:
> 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)


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl