Re: deprecating fix->mmio_start and smem_start

["Scott D. Davilla" <davilla@4pi.com>]

>On Tue, 22 Apr 2008, Scott D. Davilla wrote:
>>  >On Tue, 22 Apr 2008, Benjamin Herrenschmidt wrote:
>>  >>  We currently have a problem with those two members of struct
>>  >>  fb_fix_screeninfo. The struct contains an "unsigned long" which means
>>  >>  that:
>>  >>
>>  >>  - 64 bits kernels with 32 bits userspace can't pass a complete address
>>  >>  - 32 bits machines with 64 bits resource_size_t can't pass a complete
>>  >>  address
>>  >>  - The structure isn't even properly padded to be 32/64 bits neutral in
>>  >>  the first place.
>>  >>
>>  >  > We could define new versions of the struct with new get/set ioctls,
>>  >>  or we could try to just deprecate those fields. What do you guys think ?
>>  >
>>  >As userspace doesn't really need those fields[1], we can easily
>>  >deprecate them.
>>
>  > kexec uses FBIOGET_FSCREENINFO and FBIOGET_VSCREENINFO. So if these
>  > ioctls changes, it will possibly break kexec under vesafb and efifb.
>
>Does kexec use the smem_start and mmio_start fields of
>fb_fix_screeninfo?
>

In "kexec/arch/i386/x86-linux-setup.c", the routine 
"setup_linux_vesafb" uses smem_start, smem_len, and line_length.

This is used for vesafb and efifb framebuffer kernel boot param 
setup. This is required for PC hardware that do not contain a PC-BIOS 
and need the bootloader to setup the kernel video boot params.



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone