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. > 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? Either way, I see no documentation being added to the Documentation/ABI/ directory describing what is happening here, that needs to be added at the least. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
