quoted

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.

Well... yes and no. At least some X drivers use the mmio_start field to
map registers via /dev/mem no ?

quoted

If we do the later, we need another way to convey the informations.

For smem, I'm not sure it's very useful, we should just be able to mmap
the fbdev. The problem is more with mmio_start.

Thus the idea that we could do something to allow mmap'ing mmio via
mmap of /dev/fb via some specific offset... what do you think ?

That's exactly what drivers/video/fbmem.c:fb_mmap() does[2].

Ok, I had a look at it does indeed make MMIO appear after the fb. The
funny thing here is that it does use fix for that which means it's
broken on those platforms.

But fb_mmap() does need the correct (resource_size_t) information.
That can be done by changing the offending fields in the kernel variant of
fb_fix_screeninfo to resource_size_t.

Yup, and we need to add some conversion to the "user" variant.

The user variant of fb_fix_screeninfo would stay the same, and only the
FBIOGET_FSCREENINFO case in drivers/video/fbmem.c:fb_ioctl() has to be
changed to convert from the kernel to the user variant.

Yup. I could always set smem_start to 0 and mmio_stat to smem_len in
there while at it. This will break the day we have 4G of video RAM
though. Which is why I wonder if we should -also- make the new kernel
structure user-visible with a new ioctl, so that user space can migrate
and the day we have such monsters, we aren't totally broken ?

[1] Except when it wants to mmap /dev/mem using this info, but that can
    be done using [2].

Yes, but there are existing broken programs. I'm pretty sure there used
to be at least...

One option here is we can test if the values are > 32 bits, when
converting from the in-kernel 64 bits structure.

If that's not the case, we copy them as usual, thus we stay compatible
for cases that work today (such as a 64 bits G5 with 32 bits userspace
as all MMIO on the G5 is below 4G).

If they are >4G, we do something like putting 0xffffffff in smem_start
and mmio_start, which should make mmap attempts via /dev/mem to fail and
keep smem_len and mmio_len to the right values.

What do you think ?

Cheers,
Ben.



-------------------------------------------------------------------------
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