Port-xen archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [diff] Some minor corrections and improvements



Jean-Yves Migeon wrote:
> Hi list,
> 
> In an attempt to reduce my future diffs for save/restore in port-xen, I
> collected some and would like you to review them.
> 
> Changes:
> - printf => aprint_*
> - xs_init() returns an error if it fails, following christoph (cegger@)
> modifications from yesterday
> - init_events() => events_init() (closer to netbsd's semantics like
> found in init_main.c)
> - some '\n' removal in DPRINTF macros (unneeded, the format in macro
> already adds one)
> - Add and fix some typos in comments
> - align start_info_union on a page boundary. This is not strictly
> required for our current domU, but all Xen code (hypervisor and tools)
> expect the start_info struct to be page aligned.
> - mask xbd event before removing its handler.
> 
> The following are not used yet (but will be, in a not too distant
> future, after branching). I can keep them out of the diff, since all
> they add is just more bytes to the kernel.
> 
> - mfn_to_pfn and pfn_to_mfn (avoids the PAGE_SHIFT and XPMAP_OFFSET
> stuff if we only care about frame number conversions) - well, this one
> does not add bytes, they are just macros. Anyway...
> - add HYPERVISOR_crash() for i386 and amd64

the hypercall for amd64 is wrong (and it doesn't even compile).

> - change unbind_[pv]irq_from_evtch() to return the unbound evtch for the
> requested [PV]IRQ. They are now the reverse equivalent of the
> bind_[pv]irq_to_evtch ones.
> - add the "protocol" entry to xenstore during xbd initialization.
> Normally created during domU's first boot by xentools DevController, but
> is under domU's responsibility in all other cases (save/restore, hot
> plugging, whatever).
> - remove the xenbus_suspend() and xenbus_resume() prototypes, they are
> not used anywhere, and will conflict with xenbus pmf(9) handlers.
> 
> It does not seem to break anything. It compiles and works under i386,
> but is untested under amd64. No reason it shouldn't.
> 
> Please review :)

Even if you don't have a amd64 machine, you should at least
cross-compile. build.sh is your friend. :)

Christoph


Home | Main Index | Thread Index | Old Index