Hi!
> > 3) The user space reset programs have to be serialized because of the
> > rule about only a single VGA at a time. Calling vm86 from kernel mode
> > is not a good idea. Doing this in user space lets you have two reset
> > programs, vm86 and emu86 for non-x86 machines.
>
> With the approach I detailed in the thread starter, this is easily
> possible. vesaposter can call the kernel function used to synchronize
> in an endless loop and this kernel function would not only be used
> to synchronize, but its return value would tell vesaposter what to do
> to which card. An alternative would be to restart vesaposter as soon
> as it has finished its job, which would make the POSTing reliable
> even if the BIOS code hangs or causes crashes. The kernel can simply
> store a list of video devices and their respective treatments and
> the kernel function called by vesaposter would just iterate through
> the list. Hmmm... why not call it
>
> int video_helper(struct video_actions *what_to_do)
I do not know, synchronously executing userland code from kernel seems
like wrong thing to do.
> And the problem of locking all application memory: The current tool
> for POSTing and restoring video state (vbetool) uses only 27k on
> disk. If we put it in initramfs, we could maybe avoid mlock
> completely (if we can guarantee initramfs contents aren't swapped
> out). And it would be available early enough for initializing
> video hardware on boot.
I do not understand how initramfs fits into picture... Plus lot of
people (me :-) do not use initramfs...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/
