> Hell. Are you stupid or what?
Come down dude. I just want a leaner better system. To understand what is
really going on a did alot of stracing and looking threw the code line by
line this afternoon. Then I went over and over again in my head what all
this code is doing. I did a strace on chvt to see what was going on.
getpid() = 1054
open("/dev/tty", O_RDWR) = 3
ioctl(3, KDGKBTYPE, 0xbffffd2f) = 0
ioctl(3, VT_ACTIVATE, 0x5) = 0
ioctl(3, VT_WAITACTIVE, 0x5) = 0
_exit(0) = ?
Then I threw all the tty code to see where current->tty is actually set
and when it is altered. When you vt switch current->tty does not change.
PROC_CONSOLE first grabs the foreground console then it does return
current->tty if its valid. You where right. current->tty doesn't have to
equal the fore ground console if you use the VT_ACTIVATE ioctl. This means
a fbdev program started on VT# is bonded to this VT no matter how much VT
switching you do. Now I though you could get away with this because I was
always under the impression that the processes on the inactive VT went to
sleep when they where not of course run as a background process. So I
begain thinking more. Continued below.
> (1) sleep 5 is started on tty2
> (2) foreground tty is changed from tty2 to tty5. Look, no fbset running...
> (3) time passes... 1s, 2s, 3s, 4s, 5s... sleep finishes
> (4) fbset -depth 16 is started on tty2. No change on tty5 occurs.
> (5) fb_ioctl finds that PROC_CONSOLE() returns 2-1 == 1. fb_set_var(..,1,..)
> is invoked. Resolution of tty2 is changed. No change on tty5. No
> change on hardware. Even painting of any data to fb and/or tty5 by
> any process running on tty5 can proceed in parallel without any race.
> (6) fbset finishes. tty2 now uses 16bpp. tty5 unchanged.
I was always under the impression that when you VT switch that the
processes running on the VT you switched from where put to sleep. I now
realized this is not the case. I had to think about this for awhile why
this could be allowed. I begain by picturing two console programs running
at the same time on the same video card. You VT switch away from one to
the other one. Now the inactive VT still has the program running. Why is
this allowed? I realized because both consoles are writing to different
text buffers. So program on inactive doesn't screw up the display on the
active VT.
The next step was thinking if the above was always safe with /dev/fb.
Now I realize the above is not. Say the process running on tty2 was not
fbset but a program that mmaps the framebuffer and draws say random boxes
in random colors all over the framebuffer. If I did the above it would
scribble all over the the VT we switched too. Why? Because the active VT
is drawing into the framebuffer to display text at the same time as the
second process on the inactive VT is still drawing into the framebuffer
those pretty boxes. This is not good at all :( So having /dev/fb attached
to a particular tty is not such a good idea. Now even if /dev/fb wasn't
attached to a particular tty we still have problems. VT switching to any
console while a program is drawing into the framebuffer is going to screw
it up. Drawing into the framebuffer affects all VTs.
> > What is needed is spinlocks per fb_info. You shouldn't be able to change
> Currently everything non-sleeping is guarded by lock_kernel() and
> additionaly some sleeping functions by console_lock lock.
I have to think more about this to ensure that its safe to depend on the
console_lock.
Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.
James Simmons [jsimmons@linux-fbdev.org] ____/|
fbdev/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
-
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 : Tue May 23 2000 - 21:00:18 EST