Re: [Xen-devel] ignoring xenbus state transitions during shutdown

[David Lively <dlively@xxxxxxxxxxxxxxx>]

Ok --  the .shutdown callbacks are there for Linux kernels >= 2.6.16.  
So I think I want to protect this (ignore transitions) code with:
#if defined(CONFIG_KEXEC) || LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16)

(That is, ignore state transitions if kexec is enabled or if we're 
defining the shutdown callbacks.)
Right?  (Or should I instead test only for CONFIG_KEXEC there and leave 
the shutdown callbacks NULL unless KEXEC is enabled??  Either way works 
for the cases I care about.)
Dave

Keir Fraser wrote:
> Unless you care about domU kexec, you can pretty safely remove that
> system_state() check, so long as you remove the .shutdown callback hooks (in
> the same file) too.
>
>  -- Keir
>
> On 25/6/07 19:41, "David Lively" <dlively@xxxxxxxxxxxxxxx> wrote:
>
>   
> > Hi Folks -
> >   In otherend_changed() in xenbus_probe.c, the driver is trying to
> > ignore xenbus state transitions while the guest OS is shutting down.  It
> > currently does this by looking for system_state > SYSTEM_RUNNING.  But
> > system_state is not exported by some kernels that use it (e.g., SLES9
> > running in a HVM guest), so the xenbus driver can't be loaded.
> >   The comments indicate we're trying to avoid a failure that occurs when
> > there is no rootfs.  I haven't yet seen this failure (after removing the
> > code my shutdowns with PV drivers seemed to work fine, though I haven't
> > pushed hard yet), but I suspect I shouldn't be ignoring it.  I was
> > thinking it might be better to test for the screw condition (no rootfs)
> > directly, perhaps something like try vfs_stat("/", &stat) and see
> > whether it fails (??).  (These state transitions are relatively rare, so
> > it doesn't need to be a particularly cheap test.)
> >   Any other suggestions?  I've heard of the old global 'system_running',
> > but that's not used SLES9, at least.
> >
> > Thanks in Advance,
> > Dave
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >     
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel