Re: ignoring xenbus state transitions during shutdown

[David Lively <dlively@virtualiron.com>]

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@virtualiron.com> 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@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>     
>
>