Re: kexec and frame buffer

Eric W. Biederman
2005-08-12T17:11:37Z

Luca Falavigna <dktrkranz@gmail.com> writes:

> Luca Falavigna ha scritto:
>> Eric W. Biederman ha scritto:
>>
>>>>Anyway I believe you also want to look at include/linux/tty.h
>>>>at the screen_info structure. I believe that is where
>>>>all of that information is passed.
>>
>> I noticed. Maybe if we fill struct x86_linux_param_header with some values
>> obtained from struct screen_info, we should be able to "score that mid-court
>> prayer" ;)
>>
> I tried to implement a new ioctl command in fb_ioctl() in order to retrieve and
> store screen_info variables into struct x86_linux_param_header, but I got the
> same result: no messages shown in console, as I supposed.
Hmm. very odd. Sounds very much like an implementation problem.

> After that I looked at video.S, especially an interesting label called "video":
>
> # This is the main entry point called by setup.S
> # %ds *must* be pointing to the bootsector
> video: pushw %ds # We use different segments
> pushw %ds # FS contains original DS
> popw %fs
> [...]
> #ifdef CONFIG_VIDEO_SELECT
> movw %fs:(0x01fa), %ax # User selected video mode
> cmpw $ASK_VGA, %ax # Bring up the menu
> jz vid2
> [...]
>
> Video mode is stored (by bootloader, actually) at offset 0x01fa from a given
> boot sector, which should be located at physical address DEF_SETUPSEG (0x9020).
> Feel free to correct me if I'm wrong.
That is the default address, it can actually move quite a bit.

> If we could store current video mode before executing reboot_code_buffer,
> probably setup() function would take care of anything else. So we could
> implement a function (or an assembly stub) in machine_kexec which does this job.
> I think this is the best (and safest) solution.

That is why we have sys_kexec_load().
With a working ioctl (or other way to query the information) we
just need to populate screen_info from x86-linux-setup.c in /sbin/kexec.

Eric