lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 14 Sep 2007 13:25:19 +0200
From:	Cornelia Huck <cornelia.huck@...ibm.com>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] Some driver core and kobject minor patches

On Thu, 13 Sep 2007 16:37:51 -0700,
Greg KH <greg@...ah.com> wrote:

> Kay pointed out to me the other day that we are dragging around 20 bytes
> in every struct kobject and in every struct device to contain a name
> string that can be dynamically allocated instead.  For small device
> names (the majority), this savings can add up, especially with a lot of
> individual devices.
> 
> So, I started out by getting rid of the static array in the kobject
> structure, as we already were dynamically allocating space if it was
> needed.
> 
> Of course, this required a number of other minor cleanups through the
> code tree to handle places where we were incorrectly directly accessing
> the kobject name instead of using the "proper" function.  I also got
> sidetracked by a few driver core and kobject.h cleanups of macros that
> are no longer needed, or functions that no longer need to be global
> (they were never exported, so we don't have to worry about that mess...)
> 
> And I added a change to trigger a warning if we add an attribute to
> sysfs that we have already had created, to help the SCSI developers out
> with their driver model reworks.
> 
> So, here's a series of 11 patches that I've added to my tree, and will
> send to Linus when 2.6.24 is opened up.
> 
> Any review comments are appreciated.  The full diffstat is below showing
> that overall, we did get rid of more code than was added.

Neat. We can get rid of even more stuff if we remove the removed
functions from the Documentation as well.

Signed-off-by: Cornelia Huck <cornelia.huck@...ibm.com>

---
 Documentation/kobject.txt |   21 ++-------------------
 1 files changed, 2 insertions(+), 19 deletions(-)

--- linux-2.6.orig/Documentation/kobject.txt
+++ linux-2.6/Documentation/kobject.txt
@@ -54,7 +54,6 @@ embedded in larger data structures and r
 
 struct kobject {
 	const char		* k_name;
-	char			name[KOBJ_NAME_LEN];
 	struct kref		kref;
 	struct list_head	entry;
 	struct kobject		* parent;
@@ -223,18 +222,15 @@ decl_subsys(devices, &ktype_device, &dev
 is equivalent to doing:
 
 struct kset devices_subsys = {
-     .kobj = {
-	   .name = "devices",
-     },
      .ktype = &ktype_devices,
      .uevent_ops = &device_uevent_ops,
 };
-
+kobject_set_name(&devices_subsys, name);
 
 The objects that are registered with a subsystem that use the
 subsystem's default list must have their kset ptr set properly. These
 objects may have embedded kobjects or ksets. The
-following helpers make setting the kset easier:
+following helper makes setting the kset easier:
 
 
 kobj_set_kset_s(obj,subsys)
@@ -242,22 +238,9 @@ kobj_set_kset_s(obj,subsys)
 - Assumes that obj->kobj exists, and is a struct kobject.
 - Sets the kset of that kobject to the kset <subsys>.
 
-
-kset_set_kset_s(obj,subsys)
-
-- Assumes that obj->kset exists, and is a struct kset.
-- Sets the kset of the embedded kobject to the kset <subsys>.
-
-subsys_set_kset(obj,subsys)
-
-- Assumes obj->subsys exists, and is a struct subsystem.
-- Sets obj->subsys.kset.kobj.kset to the subsystem's embedded kset.
-
 void subsystem_init(struct kset *s);
 int subsystem_register(struct kset *s);
 void subsystem_unregister(struct kset *s);
-struct kset *subsys_get(struct kset *s);
-void kset_put(struct kset *s);
 
 These are just wrappers around the respective kset_* functions.
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ