Re: [PATCHv2] qla2xxx: Correct compilation issues whenCONFIG_MOUDLES=n.
From: Greg KH
Date: Tue Sep 15 2009 - 12:59:56 EST
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 2009年9月11日, 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?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/