From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754460AbZIOS0Q (ORCPT ); Tue, 15 Sep 2009 14:26:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754850AbZIOS0I (ORCPT ); Tue, 15 Sep 2009 14:26:08 -0400 Received: from avexch1.qlogic.com ([198.70.193.115]:44402 "EHLO avexch1.qlogic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754802AbZIOS0G (ORCPT ); Tue, 15 Sep 2009 14:26:06 -0400 Date: Tue, 15 Sep 2009 11:26:09 -0700 From: Andrew Vasquez To: Greg KH Cc: James Bottomley , Linux SCSI Mailing List , Randy Dunlap , Stephen Rothwell , "linux-next@vger.kernel.org" , LKML , Giridhar Malavali , Ravi Anand , Lalit Chandivade Subject: Re: [PATCHv2] qla2xxx: Correct compilation issues when CONFIG_MOUDLES=n. Message-ID: <20090915182608.GH46353@plap4-2.local> References: <20090912000742.GB12098@plap4-2.local> <20090912001752.GC12098@plap4-2.local> <20090912003808.GD12098@plap4-2.local> <20090912005446.GA11691@kroah.com> <20090912025623.GA14824@plap4-2.local> <20090912043333.GA12349@kroah.com> <1252765807.4238.74.camel@mulgrave.site> <20090915153312.GB22774@kroah.com> <1253029631.29947.156.camel@mulgrave.site> <20090915165708.GA18817@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090915165708.GA18817@kroah.com> Organization: QLogic Corporation User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 15 Sep 2009 18:25:36.0196 (UTC) FILETIME=[EB453840:01CA3631] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 15 Sep 2009, Greg KH wrote: > On Tue, Sep 15, 2009 at 10:47:11AM -0500, James Bottomley wrote: > > On Tue, 2009-09-15 at 08:33 -0700, Greg KH wrote: > > > On Sat, Sep 12, 2009 at 09:30:07AM -0500, James Bottomley wrote: > > > > On Fri, 2009-09-11 at 21:33 -0700, Greg KH wrote: > > > > > On Fri, Sep 11, 2009 at 07:56:23PM -0700, Andrew Vasquez wrote: > > > > > > On Fri, 11 Sep 2009, Greg KH wrote: > > > > > > > > > > > > > On Fri, Sep 11, 2009 at 05:38:08PM -0700, Andrew Vasquez wrote: > > > > > > > > Randy Dunlap noted: > > > > > > > > > > > > > > > > when CONFIG_MODULES=n: > > > > > > > > > > > > > > > > drivers/scsi/qla2xxx/qla_os.c:2685: error: dereferencing pointer to incomplete type > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > kobject_uevent_env(&(&vha->hw->pdev->driver->driver)->owner->mkobj.kobj, > > > > > > > > KOBJ_CHANGE, envp); > > > > > > > > > > > > > > > > Trigger kobject event on the 'struct device' hanging off the pci_dev. > > > > > > > > > > > > > > Um, why? What are you trying to do here? kobject change should not be > > > > > > > for a device, or a "normal" kobject. > > > > > > > > > > > > > > What do you expect userspace to do with this? Where have you documented > > > > > > > it? > > > > > > > > > > > > The purpose was described here: > > > > > > > > > > > > http://article.gmane.org/gmane.linux.scsi/54155 > > > > > > > > > > > > Basically we'd like to instruct user-space to retrieve a blob of data > > > > > > automatically. > > > > > > > > > > Hm, like a firmware object perhaps? > > > > > > > > > > > Original implementation used the kboject hanging off > > > > > > the module which does not exist when CONFIG_MODULES=n. It was > > > > > > suggested that perhaps an alternative would be to use 'struct device' > > > > > > kobj. Any tips on how to trigger such a driver-specific event, > > > > > > perhaps a dedicated kobject exported by the driver itself??? > > > > > > > > > > Why not use the firmware interface for it, that is what it is designed > > > > > for, and you will not have to craft any new udev rules. > > > > > > > > The data is going the wrong way to use the current firmware interface, > > > > which is designed to load data from userspace into the kernel. For this > > > > interface, we want the data to go the other way (i.e. the kernel has a > > > > blob of dump data it would like userspace to save if it can). > > > > > > Ick. > > > > It's a natural debugging event ... the user can simply program the > > system to discard the dump. > > > > > > I'd be amenable to updating the firmware interface to do this, but it > > > > looks like adding a completely new codepath, which it's not clear even > > > > belongs there. > > > > > > Well, I don't think it deserves a kobject change event, as that means > > > something a bit different to userspace today, right? > > > > Well, the documentation (in include/linux/kobject.h) does say that > > KOBJ_CHANGED is the dumping ground for events that don't match anything > > else, which this one seems to qualify as. What else do you suggest? > > Ok, I can't think of anything else at the moment, sorry. > > This is using a binary sysfs file, right? Yes, the userspace tool retrieves the dump from a binary sysfs node: /sys/class/scsi_host/hostX/device/fw_dump -- AV