Messages in this thread | | | Date | Fri, 4 Feb 2005 17:30:19 +0100 | From | Pavel Machek <> | Subject | Re: [RFC] Reliable video POSTing on resume |
| |
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 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/
| |