1. 20 Jun, 2005 4 commits
    • mochel@digitalimplant.org's avatar
      [PATCH] add klist_node_attached() to determine if a node is on a list or not. · 8b0c250b
      mochel@digitalimplant.org authored
      
      Signed-off-by: default avatarPatrick Mochel <mochel@digitalimplant.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
      diff -Nru a/include/linux/klist.h b/include/linux/klist.h
      8b0c250b
    • mochel@digitalimplant.org's avatar
      [PATCH] Add initial implementation of klist helpers. · 9a19fea4
      mochel@digitalimplant.org authored
      
      
      This klist interface provides a couple of structures that wrap around
      struct list_head to provide explicit list "head" (struct klist) and
      list "node" (struct klist_node) objects. For struct klist, a spinlock
      is included that protects access to the actual list itself. struct
      klist_node provides a pointer to the klist that owns it and a kref
      reference count that indicates the number of current users of that node
      in the list.
      
      The entire point is to provide an interface for iterating over a list
      that is safe and allows for modification of the list during the
      iteration (e.g. insertion and removal), including modification of the
      current node on the list.
      
      It works using a 3rd object type - struct klist_iter - that is declared
      and initialized before an iteration. klist_next() is used to acquire the
      next element in the list. It returns NULL if there are no more items.
      This klist interface provides a couple of structures that wrap around
      struct list_head to provide explicit list "head" (struct klist) and
      list "node" (struct klist_node) objects. For struct klist, a spinlock
      is included that protects access to the actual list itself. struct
      klist_node provides a pointer to the klist that owns it and a kref
      reference count that indicates the number of current users of that node
      in the list.
      
      The entire point is to provide an interface for iterating over a list
      that is safe and allows for modification of the list during the
      iteration (e.g. insertion and removal), including modification of the
      current node on the list.
      
      It works using a 3rd object type - struct klist_iter - that is declared
      and initialized before an iteration. klist_next() is used to acquire the
      next element in the list. It returns NULL if there are no more items.
      Internally, that routine takes the klist's lock, decrements the reference
      count of the previous klist_node and increments the count of the next
      klist_node. It then drops the lock and returns.
      
      There are primitives for adding and removing nodes to/from a klist.
      When deleting, klist_del() will simply decrement the reference count.
      Only when the count goes to 0 is the node removed from the list.
      klist_remove() will try to delete the node from the list and block
      until it is actually removed. This is useful for objects (like devices)
      that have been removed from the system and must be freed (but must wait
      until all accessors have finished).
      
      Internally, that routine takes the klist's lock, decrements the reference
      count of the previous klist_node and increments the count of the next
      klist_node. It then drops the lock and returns.
      
      There are primitives for adding and removing nodes to/from a klist.
      When deleting, klist_del() will simply decrement the reference count.
      Only when the count goes to 0 is the node removed from the list.
      klist_remove() will try to delete the node from the list and block
      until it is actually removed. This is useful for objects (like devices)
      that have been removed from the system and must be freed (but must wait
      until all accessors have finished).
      Signed-off-by: default avatarPatrick Mochel <mochel@digitalimplant.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
      diff -Nru a/include/linux/klist.h b/include/linux/klist.h
      9a19fea4
    • Dmitry Torokhov's avatar
      [PATCH] Make kobject's name be const char * · f3b4f3c6
      Dmitry Torokhov authored
      
      
      kobject: make kobject's name const char * since users should not
      	 attempt to change it (except by calling kobject_rename).
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f3b4f3c6
    • Dmitry Torokhov's avatar
      [PATCH] kobject_hotplug() should use kobject_name() · eb11d8ff
      Dmitry Torokhov authored
      
      
      kobject: kobject_hotplug should use kobject_name() instead of
               accessing kobj->name directly since for objects with
               long names it can contain garbage.
      Signed-off-by: default avatarDmitry Torokhov <dtor@mail.ru>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      eb11d8ff
  2. 28 May, 2005 1 commit
  3. 05 May, 2005 3 commits
  4. 01 May, 2005 3 commits
  5. 19 Apr, 2005 1 commit
  6. 16 Apr, 2005 2 commits
    • James Bottomley's avatar
      [PATCH] add Big Endian variants of ioread/iowrite · dae409a2
      James Bottomley authored
      
      
      In the new io infrastructure, all of our operators are expecting the
      underlying device to be little endian (because the PCI bus, their main
      consumer, is LE).
      
      However, there are a fair few devices and busses in the world that are
      actually Big Endian.  There's even evidence that some of these BE bus and
      chip types are attached to LE systems.  Thus, there's a need for a BE
      equivalent of our io{read,write}{16,32} operations.
      
      The attached patch adds this as io{read,write}{16,32}be.  When it's in,
      I'll add the first consume (the 53c700 SCSI chip driver).
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      dae409a2
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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