Re: Network: convert network devices to use struct device instead of class_device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/9/07, Kay Sievers <[email protected]> wrote:
On Thu, 2007-02-08 at 22:59 -0500, Dmitry Torokhov wrote:
> On Thursday 08 February 2007 19:56, Greg KH wrote:
> > On Thu, Feb 08, 2007 at 12:29:12PM -0500, Dmitry Torokhov wrote:
> > > On 2/8/07, Stephen Hemminger <[email protected]> wrote:
> > > >On Thu, 08 Feb 2007 07:43:18 -0500

> > > >> >     Network: convert network devices to use struct device instead of
> > > >class_device
> > > >> >
> > > >> >     This lets the network core have the ability to handle
> > > >suspend/resume
> > > >> >     issues, if it wants to.
> > > >
> > > >It fixes a non-problem. I would like to see the network core suspend/resume
> > > >proposal as well. Last time I examined doing network core suspend help,
> > > >the problem was that the physical device suspend was called before the
> > > >class device. It is not clear how this change would help.
> > >
> > > If physical devices are registered before class devices then when
> > > suspending class devices are naturally suspended first. It is still
> > > not clear to me why we need to convert everythign to struct device, I
> > > believe I've shown (with patches) that it is possible to integrate
> > > struct class_device into PM framework and avoid reshuffling half of
> > > the kernel code.
> >
> > I don't want to have two separate device trees in the kernel (well, one
> > big device tree and a bunch of little class_device trees.)  The code
> > duplication in the class_device code is just too much, and I get
> > questions all the time as to what the differences are.
> >
>
> While duplication of code is a real concern my worry is constant fattening
> of struct device. For example most physical devices do not interface
> directly with userspace but every single one of them now has dev_t.
> Former class_devices do not need suspend/resume early framework either.
> And so on, and so forth.

The dev_t is a good example for the mess we try to fix here. Not having
a dev_t for "devices" lead to the creation of a lot of otherwise
completely useless "class devices" which are just a total pain to
interpret, and follow the events they create, from userspace.

Things like the scsi_device devices, usb_device devices, ... just exist,
because only this type of devices was allowed to pass information for
device nodes to userspace.


I admit I do not know scsi stack but I would expect that the only
things that need dev_t there would be sd, sr and sg interfaces. As
such they are separate entities and "deserve" their own structures no
mater what.

I can bet that number of real devices that need dev_t is smaller than
number of virtual devices that do not need full power management:

PCI cards, ACPI tree, etc, etc - hardware devices interfacing with
other parts of the kernel, not userspace directly.

NET, input, tty, etc - no need to suspend late/resume early

And, btw, having separate device and struct device does not prevent
exporting them as a unified sysfs tree and is in fact pretty easy to
do (I believe I posted patches to do that as well).

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux