1. 16 8月, 2008 1 次提交
  2. 30 4月, 2008 1 次提交
  3. 17 10月, 2007 3 次提交
    • B
      add CONFIG_VT_UNICODE · 2e8ecb9d
      Bill Nottingham 提交于
      As of now, the kernel defaults to non-unicode and XLATE for the keyboard.
      We've been changing this in Fedora, but that requires patching the defaults
      in the kernel.
      
      The attached introduces CONFIG_VT_UNICODE, which sets the console in
      unicode mode by default on boot, including both the virtual terminal and
      the keyboard driver.
      Signed-off-by: NBill Nottingham <notting@redhat.com>
      Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2e8ecb9d
    • S
      unicode diacritics support · 04c71976
      Samuel Thibault 提交于
      There have been issues with non-latin1 diacritics and unicode.
      http://bugzilla.kernel.org/show_bug.cgi?id=7746
      
      Git 759448f4 `Kernel utf-8 handling'
      partly resolved it by adding conversion between diacritics and
      unicode. The patch below goes further by just turning diacritics into
      unicode, hence providing better future support. The kbd support can be
      fetched from
      http://bugzilla.kernel.org/attachment.cgi?id=12313
      
      This was tested in all of latin1, latin9, latin2 and unicode with french
      and czech dead keys.
      
      Turn the kernel accent_table into unicode, and extend ioctls KDGKBDIACR
      and KDSKBDIACR into their equivalents KDGKBDIACRUC and KDSKBDIACR.
      
      New function int conv_uni_to_8bit(u32 uni) for converting unicode into 8bit
      _input_.  No, we don't want to store the translation, as it is potentially
      sparse and large.
      Signed-off-by: NSamuel Thibault <samuel.thibault@ens-lyon.org>
      Cc: Jan Engelhardt <jengelh@gmx.de>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      04c71976
    • A
      vt/vgacon: Check if screen resize request comes from userspace · e400b6ec
      Antonino A. Daplas 提交于
      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: NAntonino Daplas <adaplas@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e400b6ec
  4. 08 10月, 2007 1 次提交
    • L
      VT_WAITACTIVE: Avoid returning EINTR when not necessary · 70cb9793
      Linus Torvalds 提交于
      We should generally prefer to return ERESTARTNOHAND rather than EINTR,
      so that processes with unhandled signals that get ignored don't return
      EINTR.
      
      This can help with X startup issues:
      
          Fatal server error:
          xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
      
      although the real fix is having the X server always retry EINTR
      regardless (since EINTR does happen for signals that have handlers
      installed). Keithp has a patch for that.
      
      Regardless, ERESTARTNOHAND is the correct thing to use.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      70cb9793
  5. 01 10月, 2007 1 次提交
  6. 30 9月, 2007 1 次提交
    • J
      fix console change race exposed by CFS · a64314e6
      Jan Lübbe 提交于
      The new behaviour of CFS exposes a race which occurs if a switch is
      requested when vt_mode.mode is VT_PROCESS.
      
      The process with vc->vt_pid is signaled before vc->vt_newvt is set.
      This causes the switch to fail when triggered by the monitoing process
      because the target is still -1.
      
      [ If the signal sending fails, the subsequent "reset_vc(vc)" will then
        reset vt_newvt to -1, so this works for that case too.   - Linus ]
      Signed-off-by: NJan Lübbe <jluebbe@lasnet.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a64314e6
  7. 09 5月, 2007 1 次提交
  8. 03 4月, 2007 1 次提交
  9. 17 3月, 2007 1 次提交
  10. 12 2月, 2007 1 次提交
    • E
      [PATCH] vt: refactor console SAK processing · 8b6312f4
      Eric W. Biederman 提交于
      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: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8b6312f4
  11. 14 12月, 2006 2 次提交
    • R
      [PATCH] getting rid of all casts of k[cmz]alloc() calls · 5cbded58
      Robert P. J. Day 提交于
      Run this:
      
      	#!/bin/sh
      	for f in $(grep -Erl "\([^\)]*\) *k[cmz]alloc" *) ; do
      	  echo "De-casting $f..."
      	  perl -pi -e "s/ ?= ?\([^\)]*\) *(k[cmz]alloc) *\(/ = \1\(/" $f
      	done
      
      And then go through and reinstate those cases where code is casting pointers
      to non-pointers.
      
      And then drop a few hunks which conflicted with outstanding work.
      
      Cc: Russell King <rmk@arm.linux.org.uk>, Ian Molton <spyro@f2s.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Paul Fulghum <paulkf@microgate.com>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Karsten Keil <kkeil@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Cc: Jaroslav Kysela <perex@suse.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5cbded58
    • E
      [PATCH] vt: fix comments to not refer to kill_proc · 3dfcaf16
      Eric W. Biederman 提交于
      The code has been fixed to use kill_pid instead of kill_proc fix the
      comments as well.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3dfcaf16
  12. 02 10月, 2006 2 次提交
    • E
      [PATCH] vt: Make vt_pid a struct pid (making it pid wrap around safe). · bde0d2c9
      Eric W. Biederman 提交于
      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: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bde0d2c9
    • E
      [PATCH] vt: rework the console spawning variables · 81af8d67
      Eric W. Biederman 提交于
      This is such a rare path it took me a while to figure out how to test
      this after soring out the locking.
      
      This patch does several things.
      - The variables used are moved into a structure and declared in vt_kern.h
      - A spinlock is added so we don't have SMP races updating the values.
      - Instead of raw pid_t value a struct_pid is used to guard against
        pid wrap around issues, if the daemon to spawn a new console dies.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      81af8d67
  13. 30 9月, 2006 1 次提交
    • A
      [PATCH] tty locking on resize · ca9bda00
      Alan Cox 提交于
      The current kernel serializes console resizes but does not serialize the
      resize against the tty structure updates.  This means that while two
      parallel resizes cannot mess up the console you can get incorrect results
      reported.
      
      Secondly while doing this I added vc_lock_resize() to lock and resize the
      console.  This leaves all knowledge of the console_sem in the vt/console
      driver and kicks it out of the tty layer, which is good
      
      Thirdly while doing this I decided I couldn't stand "disallocate" any
      longer so I switched it to "deallocate".
      Signed-off-by: NAlan Cox <alan@redhat.com>
      Cc: Paul Fulghum <paulkf@microgate.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ca9bda00
  14. 28 8月, 2006 1 次提交
  15. 01 7月, 2006 1 次提交
  16. 07 11月, 2005 1 次提交
  17. 31 10月, 2005 1 次提交
  18. 29 6月, 2005 1 次提交
  19. 01 5月, 2005 1 次提交
  20. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4