On 15 Mar 2000, Marcus Sundberg wrote:
> James A Simmons <jsimmons@acsu.buffalo.edu> writes:
>
> > Here is the main reasons why I have it so only one app can open /dev/fb at
> > a time. Its called SMP. Consider two apps running at the same time both
> > with /dev/fb opened. Problem:
>
> SMP is no different from UP as far as graphics hardware is concerned.
> The PCI/AGP bus will serialize accesses and the card will not notice
> any difference between SMP and two processes task switching in UP.
See my other post about multiple access. What I'm talking about is the
different state the hardware can be in per process. Even with one process
allowed a write and a bunch of reads that data they could be reading could
be altered by the one app thats allowed write access to change modes.
I'm talking about the hardware context. The video card can be in
different state for each process.
> > Now do people agree with me that /dev/fb should only be opened once.
>
> No.
> Having several fbdev apps sleeping on several incative VTs while
> you are running another on the current VT must be possible, otherwise
> you are removing important functionality.
I'm talking about running several fbdev apps on top of the same VT. Of
course I see where VT switching can cause problems too :(
> It's most probably too late to redesign fbdev for safe user access
> for 2.4, but in any case only allowing one open() is not the right
> way for 2.4 or any future kernel version. If you want some safety
> for 2.4, then only allow root processes to map the MMIO region.
It more than MMIO region access. See my other post about what could go
wrong. It true this feature has been removed and will be in placed for
2.5.X. Breaking things now would be a bad idea with 2.4.X coming out.
You right it to late now. By the way sparc fbdev driver have been doing it
this way. They got it right from the start.
P.S
Another big problem is fork. Consider a card with different apertures
for big endian and little endian. The little endian is used for 8 and less
bpp mode and big endian is used for 16+ bpp modes. Imagine this scratch
code
int main()
open("/dev/fb)
ioctl(FBIOSETVAR ..(var));
pid = fork();;
if (pid ...)
/* child */
ioctl(FBIOSETVAR)
else
/* parent */
memset(fix->smem_start, fix-smem_len, 0xFFFF);
}
Now the parent is writing to the framebuffer. Now if the child changes the
mode while the parent is writing to the framebuffer and it changes from
little endian to big endian aperture it cokes. So for /dev/fb the mapping
and file descriptors shouldn't be inherited to child.
"Look its a text editor, no its a OS, no its Emacs"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST