1. 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
  2. 16 9月, 2009 1 次提交
  3. 20 4月, 2008 1 次提交
  4. 08 4月, 2008 1 次提交
    • J
      [SCSI] transport_class: BUG if we can't release the attribute container · 2f3edc69
      James Bottomley 提交于
      Every current transport class calls transport_container_release but
      ignores the return value.  This is catastrophic if it returns an error
      because the containers are part of a global list and the next action of
      almost every transport class is to free the memory used by the
      container.
      
      Fix this by making transport_container_release a void, but making it BUG
      if attribute_container_release returns an error ... this catches the
      root cause of a system panic much earlier.  If we don't do this, we get
      an eventual BUG when the attribute container list notices the corruption
      caused by the freed memory it's still referencing.
      
      Also made attribute_container_release __must_check as a reminder.
      
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      2f3edc69
  5. 24 1月, 2008 1 次提交
  6. 17 7月, 2007 1 次提交
  7. 31 8月, 2005 1 次提交
    • J
      [SCSI] correct attribute_container list usage · 53c165e0
      James Bottomley 提交于
      One of the changes in the attribute_container code in the scsi-misc tree
      was to add a lock to protect the list of devices per container.  This,
      unfortunately, leads to potential scheduling while atomic problems if
      there's a sleep in the function called by a trigger.
      
      The correct solution is to use the kernel klist infrastructure instead
      which allows lockless traversal of a list.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      53c165e0
  8. 29 8月, 2005 1 次提交
  9. 15 8月, 2005 1 次提交
    • J
      [SCSI] correct transport class abstraction to work outside SCSI · d0a7e574
      James Bottomley 提交于
      I recently tried to construct a totally generic transport class and
      found there were certain features missing from the current abstract
      transport class.  Most notable is that you have to hang the data on the
      class_device but most of the API is framed in terms of the generic
      device, not the class_device.
      
      These changes are two fold
      
      - Provide the class_device to all of the setup and configure APIs
      - Provide and extra API to take the device and the attribute class and
        return the corresponding class_device
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      d0a7e574
  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
反馈
建议
客服 返回
顶部