1. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  2. 12 6月, 2009 1 次提交
  3. 02 8月, 2008 1 次提交
  4. 09 2月, 2008 1 次提交
  5. 12 2月, 2007 1 次提交
    • T
      [PATCH] consolidate line discipline number definitions · 4564f9e5
      Tilman Schmidt 提交于
      The line discipline numbers N_* are currently defined for each architecture
      individually, but (except for a seeming mistake) identically, in
      asm/termios.h.  There is no obvious reason why these numbers should be
      architecture specific, nor any apparent relationship with the termios
      structure.  The total number of these, NR_LDISCS, is defined in linux/tty.h
      anyway.  So I propose the following patch which moves the definitions of
      the individual line disciplines to linux/tty.h too.
      
      Three of these numbers (N_MASC, N_PROFIBUS_FDL, and N_SMSBLOCK) are unused
      in the current kernel, but the patch still keeps the complete set in case
      there are plans to use them yet.
      Signed-off-by: NTilman Schmidt <tilman@imap.cc>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4564f9e5
  6. 04 12月, 2006 1 次提交
  7. 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