Messages in this thread | | | Subject | Re: [linux-fbdev] fbdev 2.4.0 cleanups | From | Marcus Sundberg <> | Date | 15 Mar 2000 15:23:58 +0100 |
| |
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.
> 1) > Both apps mmap the MMIO region. Both program the accel engine at the > same. Hey the card locks up. > > 2) > DRI and fbdev MMIO region. DRI is using accel engine. Some app running > from a xterm mmaps MMIO region then uses accel engine. The card locks up. > > 3) > Someone runs fbset while the X server is using accel engine via /dev/fb > or DRI. Card locks up. You should only change the mode when the accel > engine is idle.
Then don't do it.
> 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.
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.
//Marcus -- Signature under construction, please come back later.
- 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/
| |