From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752770AbXDWGlZ (ORCPT ); Mon, 23 Apr 2007 02:41:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753077AbXDWGlW (ORCPT ); Mon, 23 Apr 2007 02:41:22 -0400 Received: from wx-out-0506.google.com ([66.249.82.236]:33340 "EHLO wx-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752770AbXDWGlV (ORCPT ); Mon, 23 Apr 2007 02:41:21 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=miFfHlOA/+gony+CYMRU43RdCEb0WBqSyLa6uCY0rmp3h+Krty1qjFJdvQ1rKN7HIEGrz+KSOEgWxdw/xB34oOzFDmuWXhtrvOMZ89F4vSB470Sp/AkABIygvCOQBcAbmv/EUr4tnVOqze/6xjzjT+whH3GMAUpy+jo4GMmyRKo= Message-ID: <462C54D5.6000101@gmail.com> Date: Mon, 23 Apr 2007 15:40:21 +0900 From: Tejun Heo User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Dmitry Torokhov CC: Cornelia Huck , Alan Stern , linux-kernel , Greg K-H , Rusty Russell Subject: Re: [PATCH RFD] alternative kobject release wait mechanism References: <46263A82.1030703@gmail.com> <20070419145133.2f7ed45a@gondolin.boeblingen.de.ibm.com> <20070419154849.2e722762@gondolin.boeblingen.de.ibm.com> <462856B9.9010307@gmail.com> <4628EFB2.9070709@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hello, Dmitry. Dmitry Torokhov wrote: > Isn't think a good thing? By decoupling the 2 layers we insulate them > from changes in each other. This allows bug subsystems to concentrate > on topics that important to them instead of worying about refcounting > objects that are not directly interesting for the subsystem in > question. I think the best thing would be make struct device's lifetime rules simple enough such that it doesn't really matter to driver subsystems and drivers can just do what they wanna do. Also, separate struct device from the actual implementation has problem in that struct device is widely used to refer to the device by many layers drivers register devices to. Basically, you'll have to implement immediate-disconnect between struct device and the actual implementation. So, it just shifts the problem from struct device to the place between struct device and actual implementation and I think struct device itself is better place to deal with that than somewhere inbetween it and driver private data. > Now for smaller subsystems it may make sense to embed stuct devices > into subsystem objects and manage it all together. In fact input > system does this but I think it is much simlpier than SCSI or IDE. Well, both SCSI and IDE heavily depend on struct device acting as 'base class'. It's all over the place and almost a basic assumption about the driver model. -- tejun