1. 13 7月, 2005 1 次提交
  2. 07 7月, 2005 1 次提交
  3. 28 6月, 2005 1 次提交
  4. 26 6月, 2005 2 次提交
  5. 24 6月, 2005 2 次提交
  6. 06 5月, 2005 3 次提交
    • R
      [PATCH] patch-kernel: support non-incremental 2.6.x.y 'stable' patches · 1922163c
      Randy.Dunlap 提交于
      Add better support for (non-incremental) 2.6.x.y patches; If an ending
      version number if not specified, the script automatically increments the
      SUBLEVEL (x in 2.6.x.y) until no more patch files are found; however,
      EXTRAVERSION (y in 2.6.x.y) is never automatically incremented but must be
      specified fully.
      
      patch-kernel does not normally support reverse patching, but does so when
      applying EXTRAVERSION (x.y) patches, so that moving from 2.6.11.y to
      2.6.11.z is easy and handled by the script (reverse 2.6.11.y and apply
      2.6.11.z).
      Signed-off-by: NRandy Dunlap <rddunlap@osdl.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1922163c
    • D
      [PATCH] ppc32: platform-specific functions missing from kallsyms. · 075d6eb1
      David Woodhouse 提交于
      The PPC32 kernel puts platform-specific functions into separate sections so
      that unneeded parts of it can be freed when we've booted and actually
      worked out what we're running on today.
      
      This makes kallsyms ignore those functions, because they're not between
      _[se]text or _[se]inittext.  Rather than teaching kallsyms about the
      various pmac/chrp/etc sections, this patch adds '_[se]extratext' markers
      for kallsyms.
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      075d6eb1
    • A
      [PATCH] Kconfig i18n support · 3b9fa093
      Arnaldo Carvalho de Melo 提交于
      This patch adds i18n support for make *config, allowing users to have the
      config process in their own language.
      
      No printk was harmed in the process, don't worry, so all the bug reports,
      kernel messages, etc, remain in english, just the user tools to configure
      the kernel are internationalized.
      
      Users not interested in translations can just unset the related LANG,
      LC_ALL, etc env variables and have the config process in plain english,
      something like:
      
      LANG= make menuconfig
      
      is enough for having the whole config process in english. Or just don't
      install any translation file.
      
      Translations for brazilian portuguese are being done by a team of
      volunteers at:
      
      http://www.visionflex.inf.br/kernel_ptbr/pmwiki.php/Principal/Traducoes
      
      To start the translation process:
      
        make update-po-config
      
        This will generate the pot template named scripts/kconfig/linux.pot,
        copy it to, say, ~/es.po, to start the translation for spanish.
      
      To test your translation, as root issue this command:
      
        msgfmt -o /usr/share/locale/es/LC_MESSAGES/linux.mo ~/es.po
      
        Replace "es" with your language code.
      
        Then execute, for instance:
      
        make menuconfig
      
      The current patch doesn't use any optimization to reduce the size of the
      generated .mo file, it is possible to use the config option as a key, but
      this doesn't prevent the current patch from being used or the translations
      done under the current scheme to be in any way lost if we chose to do any
      kind of keying.
      
      Thanks to Fabricio Vaccari for starting the pt_BR (brazilian portuguese)
      translation effort, Thiago Maciera for helping me with the gconf.cc (QT
      frontent) i18n coding and to all the volunteers that are already working on
      the first translation, to pt_BR.
      
      I left the question on whether to ship the translations with the stock kernel
      sources to be discussed here, please share your suggestions.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@conectiva.com.br>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: Linus Torvalds <torvalds@osdl.org
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      3b9fa093
  7. 01 5月, 2005 5 次提交
  8. 23 4月, 2005 1 次提交
    • R
      [PATCH] USB: scripts/mod/file2alias.c: handle numeric ranges for USB bcdDevice · b19dcd93
      Roman Kagan 提交于
      Another attempt at that...
      
      The attached patch fixes the longstanding problem with USB bcdDevice
      numeric ranges incorrectly converted into patterns for MODULE_ALIAS
      generation.  Previously it put both the lower and the upper limits into
      the pattern, dlXdhY, making it impossible to fnmatch against except for
      a few special cases, like dl*dh* or dlXdhX.
      
      The patch makes it generate multiple MODULE_ALIAS lines covering the
      whole range with fnmatch-able patterns.  E.g. for a range between 0x0001
      and 0x8345 it gives the following patterns:
      
      000[1-9]
      00[1-9]*
      0[1-9]*
      [1-7]*
      8[0-2]*
      83[0-3]*
      834[0-5]
      
      Since bcdDevice is 2 bytes wide = 4 digits in hex representation, the
      max no. of patters is 2 * 4 - 1 = 7.
      
      The values are BCD (binary-coded decimals) and not hex, so patterns
      using a dash seem to be safe regardless of locale collation order.
      
      The patch changes bcdDevice part of the alias from dlXdhY to dZ, but
      this shouldn't have big compatibility issues because fnmatch()-based
      modprobing hasn't yet been widely used.  Besides, the most common (and
      almost the only working) case of dl*dh* becomes d* and thus continues to
      work.
      
      The patch is against 2.6.12-rc2, applies to -mm3 with an offset.  The
      matching patch to fix the MODALIAS environment variable now generated by
      the usb hotplug function follows.
      Signed-off-by: NRoman Kagan <rkagan@mail.ru>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      b19dcd93
  9. 19 4月, 2005 1 次提交
  10. 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