linux-kernel - question about drivers/infiniband/core/cm.c's kobject usage

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-next>] [day] [month] [year] [list]

Date:	Thu, 22 May 2008 13:34:03 -0700
From:	Greg KH <greg@...ah.com>
To:	Sean Hefty <sean.hefty@...el.com>
Cc:	rolandd@...co.com, hal.rosenstock@...il.com,
	general@...ts.openfabrics.org, linux-kernel@...r.kernel.org
Subject: question about drivers/infiniband/core/cm.c's kobject usage

Hi,

I was working on some changes to the driver core that is cleaning up the
struct class fields, when I ran accross the usage of cm.c and the
infiniband_cm class.

It looks like you are registering "raw" kobjects in this class, chaining
things off of it, as if they were devices.

If so, why not just use struct device in the first place?  You are
creating a tree, which on modern distros, userspace will never see as
they are expecting everything to be showing up in /sys/devices/

Entries in /sys/class/*/* now are symlinks into the /sys/devices tree,
showing the representation of everything in one tree, not lots of little
trees all over the place.

So I was curious, was this done on purpose?  If so, why?  If not, any
objection to me switching it over to be using struct device properly?

thanks,

greg k-h
--
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/