From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [PATCHv2] qla2xxx: Correct compilation issues when CONFIG_MOUDLES=n. Date: Tue, 15 Sep 2009 11:29:03 -0700 Message-ID: <20090915182903.GA32540@kroah.com> References: <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=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from kroah.org ([198.145.64.141]:35824 "EHLO coco.kroah.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758357AbZIOTH0 (ORCPT ); Tue, 15 Sep 2009 15:07:26 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: To: Kay Sievers Cc: James Bottomley , Andrew Vasquez , Linux SCSI Mailing List , Randy Dunlap , Stephen Rothwell , "linux-next@vger.kernel.org" , LKML , Giridhar Malavali , Ravi Anand , Lalit Chandivade On Tue, Sep 15, 2009 at 07:22:03PM +0200, Kay Sievers wrote: > On Tue, Sep 15, 2009 at 18:57, 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 wro= te: > >> > > > > On Fri, 11 Sep 2009, Greg KH wrote: > >> > > > > > >> > > > > > On Fri, Sep 11, 2009 at 05:38:08PM -0700, Andrew Vasquez= wrote: > >> > > > > > > Randy Dunlap noted: > >> > > > > > > > >> > > > > > > =A0 when CONFIG_MODULES=3Dn: > >> > > > > > > > >> > > > > > > =A0 drivers/scsi/qla2xxx/qla_os.c:2685: error: derefer= encing pointer to incomplete type > >> > > > > > > > >> > > > > > > =A0 in > >> > > > > > > > >> > > > > > > =A0 kobject_uevent_env(&(&vha->hw->pdev->driver->drive= r)->owner->mkobj.kobj, > >> > > > > > > =A0 =A0 =A0 =A0 =A0 KOBJ_CHANGE, envp); > >> > > > > > > > >> > > > > > > Trigger kobject event on the 'struct device' hanging o= ff the pci_dev. > >> > > > > > > >> > > > > > Um, why? =A0What are you trying to do here? =A0kobject c= hange should not be > >> > > > > > for a device, or a "normal" kobject. > >> > > > > > > >> > > > > > What do you expect userspace to do with this? =A0Where h= ave you documented > >> > > > > > it? > >> > > > > > >> > > > > The purpose was described here: > >> > > > > > >> > > > > =A0 =A0 =A0 http://article.gmane.org/gmane.linux.scsi/5415= 5 > >> > > > > > >> > > > > Basically we'd like to instruct user-space to retrieve a b= lob 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=3Dn. =A0= It was > >> > > > > suggested that perhaps an alternative would be to use 'str= uct device' > >> > > > > kobj. =A0Any 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 i= s 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 in= terface, > >> > > which is designed to load data from userspace into the kernel.= =A0For this > >> > > interface, we want the data to go the other way (i.e. the kern= el 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 cl= ear 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 any= thing > >> else, which this one seems to qualify as. =A0What else do you sugg= est? > > > > Ok, I can't think of anything else at the moment, sorry. >=20 > Wouldn't kernel/kmod.c :: call_usermodehelper_pipe() somehow fit for > that interface? Ah, yeah, good idea. Anyone tried that? thanks, greg k-h