linux-kernel - Re: [PATCH 26/47] Driver core: add groups support to struct device

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:	Tue, 26 Sep 2006 06:46:54 -0700
From:	Greg KH <greg@...ah.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Kay Sievers <kay.sievers@...y.org>
Cc:	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH 26/47] Driver core: add groups support to struct device

On Tue, Sep 26, 2006 at 09:20:17AM -0400, Dmitry Torokhov wrote:
> On 9/26/06, Greg KH <greg@...ah.com> wrote:
> >From: Greg Kroah-Hartman <gregkh@...e.de>
> >
> >This is needed for the network class devices in order to be able to
> >convert over to use struct device.
> >
> 
> Greg,
> 
> You keep pushing out patches that merge class devices and standard
> devices but you still have not shown the usefullness of this process.

I have not?  This has been discussed before.

> Why do you feel the need to change internal kernel structures
> (ever-expanding struct device to accomodate everything that is in
> struct class_device) when it should be possible to simply adjust sysfs
> representation of the kernel tree (moving class devices into
> /sys/device/.. part of the tree)  to udev's liking and leave the rest
> of the kernel alone. You have seen the patch, only minor changes in
> driver/base/class.c are needed to accomplish the move.

Think about suspend.  We want a single device tree so that the class
gets called when a device is about to be suspended so that it could shut
down the network queue in a common way, before the physical device is
called.

It's also needed if we want to have a single device tree in general.
class_device was the wrong thing and is really just a duplicate of
struct device in the first place (the driver core code implementing it
is pretty much just a cut and paste job.)  The fact that we were
arbritrary marking it different has caused problems (look at the mess
that input causes to the class_device code, that's just not nice).

Kay also has a long list of the reasons why, I think he's posted it here
before.  Kay, care to send that list again?

> I really disappointed that there was no discussion/review of the
> implementation at all.

There has not been any real implementation yet, only a few patches added
to the core that add a few extra functionality to struct device to allow
class_device to move that way.  The patches that move the subsystems
over will be discussed (and some already have, like networking), when
they are ready.  Right now most of that work is being done by Kay and
myself as a proof of concept to make sure that we can do this properly
and that userspace can handle it well.

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/