From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946530AbXBIP2b (ORCPT ); Fri, 9 Feb 2007 10:28:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946533AbXBIP2b (ORCPT ); Fri, 9 Feb 2007 10:28:31 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]:56234 "EHLO ug-out-1314.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1946530AbXBIP23 (ORCPT ); Fri, 9 Feb 2007 10:28:29 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PhDqPO1k7B6+FuX55MdbyiFfD84Q75ZaFn7H8KFC0KPwE84UlMim61bwecELwT2ZofRpos53KruOA4o7PxYYe5rjJ0d9hmFgoj34Sx7RwI3zrYj+WpzORadYss2iwXGBRQXtSPuHAK8MS7op6cgs7ZazjWKEks04CMAGrg4MqC4= Message-ID: Date: Fri, 9 Feb 2007 10:28:28 -0500 From: "Dmitry Torokhov" To: "Kay Sievers" Subject: Re: Network: convert network devices to use struct device instead of class_device Cc: "Greg KH" , "Stephen Hemminger" , "Jeff Garzik" , "Linux Kernel Mailing List" , netdev In-Reply-To: <1171009322.10605.39.camel@pim.off.vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200702080400.l1840lFd002314@hera.kernel.org> <20070209005601.GE30794@kroah.com> <200702082259.47685.dtor@insightbb.com> <1171009322.10605.39.camel@pim.off.vrfy.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 2/9/07, Kay Sievers 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 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