summaryrefslogtreecommitdiffstats
path: root/include/linux/console_struct.h
Commit message (Collapse)AuthorAgeFilesLines
* vt/vgacon: Check if screen resize request comes from userspaceAntonino A. Daplas2007-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Various console drivers are able to resize the screen via the con_resize() hook. This hook is also visible in userspace via the TIOCWINSZ, VT_RESIZE and VT_RESIZEX ioctl's. One particular utility, SVGATextMode, expects that con_resize() of the VGA console will always return success even if the resulting screen is not compatible with the hardware. However, this particular behavior of the VGA console, as reported in Kernel Bugzilla Bug 7513, can cause undefined behavior if the user starts with a console size larger than 80x25. To work around this problem, add an extra parameter to con_resize(). This parameter is ignored by drivers except for vgacon. If this parameter is non-zero, then the resize request came from a VT_RESIZE or VT_RESIZEX ioctl and vgacon will always return success. If this parameter is zero, vgacon will return -EINVAL if the requested size is not compatible with the hardware. The latter is the more correct behavior. With this change, SVGATextMode should still work correctly while in-kernel and stty resize calls can expect correct behavior from vgacon. Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Protect <linux/console_struct.h> from multiple inclusionRobert P. J. Day2007-06-081-0/+5
| | | | | | | | | | Prevent <linux/console_struct.h> from being included more than once, otherwise you get a redefinition error if you happen to include <linux/vt_kern.h> first. Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* vt: add color support to the "underline" and "italic" attributesJan Engelhardt2007-05-081-0/+3
| | | | | | | | | | Add color support to the "underline" and "italic" attributes as in OpenBSD/NetBSD-style (vt220) and xterm. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Acked-by: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] vt: refactor console SAK processingEric W. Biederman2007-02-111-0/+3
| | | | | | | | | | | | | | | | | | | | This does several things. - It moves looking up of the current foreground console into process context where we can safely take the semaphore that protects this operation. - It uses the new flavor of work queue processing. - This generates a factor of do_SAK, __do_SAK that runs immediately. - This calls __do_SAK with the console semaphore held ensuring nothing else happens to the console while we process the SAK operation. - With the console SAK processing moved into process context this patch removes the xchg operations that I used to attempt to attomically update struct pid, because of the strange locking used in the SAK processing. With SAK using the normal console semaphore nothing special is needed. Cc: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] vt: Make vt_pid a struct pid (making it pid wrap around safe).Eric W. Biederman2006-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | I took a good hard look at the locking and it appears the locking on vt_pid is the console semaphore. Every modified path is called under the console semaphore except reset_vc when it is called from fn_SAK or do_SAK both of which appear to be in interrupt context. In addition I need to be careful because in the presence of an oops the console_sem may be arbitrarily dropped. Which leads me to conclude the current locking is inadequate for my needs. Given the weird cases we could hit because of oops printing instead of introducing an extra spin lock to protect the data and keep the pid to signal and the signal to send in sync, I have opted to use xchg on just the struct pid * pointer instead. Due to console_sem we will stay in sync between vt_pid and vt_mode except for a small window during a SAK, or oops handling. SAK handling should kill any user space process that care, and oops handling we are broken anyway. Besides the worst that can happen is that I try to send the wrong signal. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] vt: Remove VT-specific declarations and definitions from tty.hJon Smirl2006-07-101-0/+1
| | | | | | | | | | | | | MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h allows all of the framebuffer and VT console drivers to remove their dependency on tty.h. [akpm@osdl.org: fix alpha build] Signed-off-by: Jon Smirl <jonsmir@gmail.com> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] console: Fix compile errorAntonino A. Daplas2005-11-071-0/+2
| | | | | | | | | | Fix following compile error (From Kernel Bugzilla Bug 5427): include/linux/console_struct.h:53: error: field `vt_mode' has incomplete type Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+123
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
OpenPOWER on IntegriCloud