Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264067AbTFPRou (ORCPT ); Mon, 16 Jun 2003 13:44:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264069AbTFPRot (ORCPT ); Mon, 16 Jun 2003 13:44:49 -0400 Received: from air-2.osdl.org ([65.172.181.6]:37862 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S264067AbTFPRor (ORCPT ); Mon, 16 Jun 2003 13:44:47 -0400 Date: Mon, 16 Jun 2003 11:00:31 -0700 (PDT) From: Patrick Mochel X-X-Sender: mochel@cherise To: Alan Stern cc: Russell King , Greg KH , Subject: Re: Flaw in the driver-model implementation of attributes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1378 Lines: 33 > > In the pcmcia case, we effectively own the object (class device) we're > > attaching the files to, so we can ensure that the module is not unloaded > > until the class device files are closed and all references to the object > > are gone. > > > > IMO, if you don't own the object (and therefore don't know its lifetime), > > you shouldn't be adding sysfs or device model attributes of any kind to > > that object. > > That's not practical. How else can a device driver provide > device-specific configuration options or information in sysfs? In many > cases the device is owned by the bus, not the device driver. Read it again. :) The driver is able to create a class-specific object for the device, which it owns entirely. Russell is suggesting that if you're going to export attributes, you best be doing them as attributes of the object you own. Otherwise, if you're a subordinate module, then you should explicitly increment the refcount of the module of the object you're exporting attributes for, and decrement it when your module is unloaded. Then again, this may happen implicitly with modules.. -pat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/