lkml.org 
[lkml]   [2005]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Reliable video POSTing on resume
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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.078 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site