1. 11 7月, 2006 1 次提交
    • C
      [PATCH] disallow modular binfmt_elf32 · 289fbc21
      Christoph Hellwig 提交于
      Currently most architectures either always build binfmt_elf32 in the kernel
      image or make it a boolean option.  Only sparc64 and s390 allow to build it
      modularly.  This patch turns the option into a boolean aswell because elf
      requires various symbols that shouldn't be available to modules.  The most
      urgent one is tasklist_lock whos export this patch series kills, but there
      are others like force_sgi aswell.
      
      Note that sparc doesn't allow a modular 32bit a.out handler either, and
      that would be the more useful case as only few people want 32bit sunos
      compatibility and 99.9% of all sparc64 users need 32bit linux native elf
      support.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: N"David S. Miller" <davem@davemloft.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      289fbc21
  2. 20 6月, 2006 1 次提交
    • D
      [SPARC64]: Move over to GENERIC_HARDIRQS. · e18e2a00
      David S. Miller 提交于
      This is the long overdue conversion of sparc64 over to
      the generic IRQ layer.
      
      The kernel image is slightly larger, but the BSS is ~60K
      smaller due to the reduced size of struct ino_bucket.
      
      A lot of IRQ implementation details, including ino_bucket,
      were moved out of asm-sparc64/irq.h and are now private to
      arch/sparc64/kernel/irq.c, and most of the code in irq.c
      totally disappeared.
      
      One thing that's different at the moment is IRQ distribution,
      we do it at enable_irq() time.  If the cpu mask is ALL then
      we round-robin using a global rotating cpu counter, else
      we pick the first cpu in the mask to support single cpu
      targetting.  This is similar to what powerpc's XICS IRQ
      support code does.
      
      This works fine on my UP SB1000, and the SMP build goes
      fine and runs on that machine, but lots of testing on
      different setups is needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e18e2a00
  3. 19 4月, 2006 1 次提交
  4. 10 4月, 2006 1 次提交
  5. 27 3月, 2006 1 次提交
    • A
      [PATCH] bitops: sparc64: use generic bitops · 2d78d4be
      Akinobu Mita 提交于
      - remove __{,test_and_}{set,clear,change}_bit() and test_bit()
      - remove ffz()
      - remove __ffs()
      - remove generic_fls()
      - remove generic_fls64()
      - remove sched_find_first_bit()
      - remove ffs()
      
      - unless defined(ULTRA_HAS_POPULATION_COUNT)
      
        - remove generic_hweight{64,32,16,8}()
      
      - remove find_{next,first}{,_zero}_bit()
      - remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit()
      - remove minix_{test,set,test_and_clear,test,find_first_zero}_bit()
      Signed-off-by: NAkinobu Mita <mita@miraclelinux.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2d78d4be
  6. 22 3月, 2006 1 次提交
  7. 20 3月, 2006 3 次提交
  8. 27 2月, 2006 1 次提交
  9. 12 1月, 2006 1 次提交
  10. 09 1月, 2006 1 次提交
  11. 23 12月, 2005 1 次提交
  12. 07 11月, 2005 1 次提交
  13. 08 9月, 2005 1 次提交
    • V
      [PATCH] Kconfig fix (BLK_DEV_FD dependencies) · a08b6b79
      viro@ZenIV.linux.org.uk 提交于
      Sanitized and fixed floppy dependencies: split the messy dependencies for
      BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
      BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
      to arch/*/Kconfig.  While we are at it, fixed several obvious cases when
      BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
      are *not* going to have floppy.c compile, let alone work).
      
      If you can come up with better name for that ("this architecture might
      have working PC-compatible floppy disk controller"), you are more than
      welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch
      below...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a08b6b79
  14. 06 9月, 2005 1 次提交
  15. 31 8月, 2005 1 次提交
  16. 12 7月, 2005 2 次提交
  17. 11 7月, 2005 1 次提交
  18. 09 7月, 2005 1 次提交
  19. 05 7月, 2005 1 次提交
    • R
      [SPARC64/COMPAT]: Add some compat ioctl for ppdev · e7270dec
      Raphael Assenat 提交于
      The following patch adds some ioctls to include/linux/compat_ioctl.h
      to allow using ppdev from the 32 bit user space on sparc64.
      
      This patch also adds the PPDEV option in the sparc64 menu, near Parallel
      printer support in the 'General machine setup' submenu.
      
      All those ioctls seem to be compatible, since (correct me if I'm wrong)
      they dont use the 'long' type. See include/linux/ppdev.h.
      
      The application I used to test the new ioctls only used the following:
      PPEXCL
      PPCLAIM
      PPNEGOT
      PPGETMODES
      PPRCONTROL
      PPWCONTROL
      PPDATADIR
      PPWDATA
      PPRDATA
      
      But I beleive that the other ioctls will work fine.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e7270dec
  20. 24 6月, 2005 1 次提交
  21. 25 4月, 2005 1 次提交
    • A
      [PATCH] missing dependency on sparc64 · e3b9ab1a
      Al Viro 提交于
      CONFIG_HW_CONSOLE selects vt.c; without the stuff pulled by CONFIG_VT it
      will not build.  Normally we get both in drivers/char/Kconfig and there
      HW_CONSOLE depends on VT.  sparc64 does not pull drivers/char/Kconfig
      and has that sutff in arch/sparc64/Kconfig instead.  However, it forgets
      to add the same dependency.  As the result, turning VT off [which is
      possible] will end up with broken build.  For no good reason... 
      Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e3b9ab1a
  22. 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