On Fri, 2009-09-11 at 10:53 -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);
>
> Signed-off-by: Andrew Vasquez <andrew.vasquez@xxxxxxxxxx>
> ---
>
> On Tue, 08 Sep 2009, Andrew Vasquez wrote:
>
> > On Mon, 07 Sep 2009, Randy Dunlap wrote:
> >
> > > On Mon, 7 Sep 2009 21:02:06 +1000 Stephen Rothwell wrote:
> > >
> > > > Hi all,
> > > >
> > > > Changes since 20090904:
> > >
> > >
> > > 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);
> >
> > Argg... Some history here... During several unwelcome
> > hardware/firmware events (ISP system error, mailbox command timeouts,
> > etc), the qla2xxx driver can store a 'firmware-dump' (essentially a
> > snapshot of the current state of the ISP firmware). This snapshot is
> > then captured via a user-space tool querying a driver sysfs-node
> > hanging off of a scsi_host's device tree:
> >
> > /sys/class/scsi_host/host4/device/fw_dump
> >
> > The dump is then used by our firmware engineering group to help triage
> > the issue.
> >
> > This recent change:
> >
> > commit 10a71b40153a19279428053ad9743e15ef414148
> > Author: Andrew Vasquez <andrew.vasquez@xxxxxxxxxx>
> > Date: Tue Aug 25 11:36:15 2009 -0700
> >
> > [SCSI] qla2xxx: Add firmware-dump kobject uevent notification.
> >
> > Signed-off-by: Andrew Vasquez <andrew.vasquez@xxxxxxxxxx>
> > Signed-off-by: Giridhar Malavali <giridhar.malavali@xxxxxxxxxx>
> > Signed-off-by: James Bottomley <James.Bottomley@xxxxxxx>
> >
> > attempted to help 'automate' the task of retrieval by signaling udev
> > to automatically run the 'retrieval' script anytime the driver
> > captured the firmware-dump. Here's a snippet of the udev rule:
> >
> > # qla2xxx driver
> > KERNEL=="qla2xxx", SUBSYSTEM=="module", ACTION=="change", RUN+="qla2xxx_udev.sh"
> >
> > Any suggestions here on an alternate driver-specific kobject an LLD
> > can/should use for something like this? I looked previously at other
> > callers of kobject_uevent_env(), but didn't really see a simlar
> > usage-pattern of a driver wanting to signal events to userspace...
> >
> > Thanks, AV
>
> Ok, So any strong objections to just having the functionality present
> when module support is enabled?
>
> diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
> index 29396c0..3887adb 100644
> --- a/drivers/scsi/qla2xxx/qla_os.c
> +++ b/drivers/scsi/qla2xxx/qla_os.c
> @@ -2671,6 +2671,7 @@ qla2x00_post_uevent_work(struct scsi_qla_host *vha, u32 code)
> static void
> qla2x00_uevent_emit(struct scsi_qla_host *vha, u32 code)
> {
> +#ifdef CONFIG_MODULES
> char event_string[40];
> char *envp[] = { event_string, NULL };
>
> @@ -2685,6 +2686,7 @@ qla2x00_uevent_emit(struct scsi_qla_host *vha, u32 code)
> }
> kobject_uevent_env(&(&vha->hw->pdev->driver->driver)->owner->mkobj.kobj,
> KOBJ_CHANGE, envp);
> +#endif
Only emitting events if the thing is compiled as a module doesn't really
look like the right solution. The first question that springs to mind
is why are you emitting events against the module kobject in the first
place? Why not emit them against the device kobject (which is always
present)?
James
--
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
