1. 02 12月, 2012 1 次提交
  2. 28 11月, 2012 1 次提交
  3. 13 10月, 2012 1 次提交
  4. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  5. 05 3月, 2012 1 次提交
    • P
      BUG: headers with BUG/BUG_ON etc. need linux/bug.h · 187f1882
      Paul Gortmaker 提交于
      If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
      other BUG variant in a static inline (i.e. not in a #define) then
      that header really should be including <linux/bug.h> and not just
      expecting it to be implicitly present.
      
      We can make this change risk-free, since if the files using these
      headers didn't have exposure to linux/bug.h already, they would have
      been causing compile failures/warnings.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      187f1882
  6. 27 11月, 2011 1 次提交
  7. 23 11月, 2011 1 次提交
  8. 27 7月, 2011 1 次提交
  9. 31 3月, 2011 1 次提交
  10. 11 12月, 2010 1 次提交
  11. 24 9月, 2010 1 次提交
  12. 09 7月, 2010 1 次提交
  13. 01 10月, 2009 1 次提交
  14. 04 12月, 2008 1 次提交
    • D
      atm: 32-bit ioctl compatibility · 8865c418
      David Woodhouse 提交于
      We lack compat ioctl support through most of the ATM code. This patch
      deals with most of it, and I can now at least use BR2684 and PPPoATM
      with 32-bit userspace.
      
      I haven't added a .compat_ioctl method to struct atm_ioctl, because
      AFAICT none of the current users need any conversion -- so we can just
      call the ->ioctl() method in every case. I looked at br2684, clip, lec,
      mpc, pppoatm and atmtcp.
      
      In svc_compat_ioctl() the only mangling which is needed is to change
      COMPAT_ATM_ADDPARTY to ATM_ADDPARTY. Although it's defined as
      	_IOW('a', ATMIOC_SPECIAL+4,struct atm_iobuf)
      it doesn't actually _take_ a struct atm_iobuf as an argument -- it takes
      a struct sockaddr_atmsvc, which _is_ the same between 32-bit and 64-bit
      code, so doesn't need conversion.
      
      Almost all of vcc_ioctl() would have been identical, so I converted that
      into a core do_vcc_ioctl() function with an 'int compat' argument.
      
      I've done the same with atm_dev_ioctl(), where there _are_ a few
      differences, but still it's relatively contained and there would
      otherwise have been a lot of duplication.
      
      I haven't done any of the actual device-specific ioctls, although I've
      added a compat_ioctl method to struct atmdev_ops.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8865c418
  15. 29 1月, 2008 1 次提交
  16. 07 9月, 2006 1 次提交
  17. 30 6月, 2006 1 次提交
  18. 26 4月, 2006 1 次提交
  19. 30 11月, 2005 3 次提交
  20. 09 10月, 2005 1 次提交
  21. 07 10月, 2005 1 次提交
  22. 05 10月, 2005 1 次提交
  23. 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