Re: [Xen-devel] Xen 4.2 Release Plan / TODO

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-04-11 at 17:11 +0100, Ian Jackson wrote:
> Ian Campbell writes ("Xen 4.2 Release Plan / TODO"):
> > Plan for a 4.2 release:
> > http://lists.xen.org/archives/html/xen-devel/2012-03/msg00793.html
> ...
> > tools, blockers:
> >       * libxl stable API -- we would like 4.2 to define a stable API
> >         which downstream's can start to rely on not changing. Aspects of
> >         this are:
> 
> I took a look at libxl.h and came up with the comments below.  Firstly
> general things I tripped over, and then the list of things which need
> converting to the new event system.

A slightly worrying list at this stage in the game.

> 
> Ian.
> 
> 
> Other:
> ======
> 
> ]   int libxl_wait_for_free_memory(libxl_ctx *ctx, uint32_t domid, uint32_t 
> memory_kb, int wait_secs);
> ]   /* wait for the memory target of a domain to be reached */
> ]   int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid, int 
> wait_secs);
> 
> This whole memory interface is a bit of a dog's breakfast.

I think we can defer this to 4.3? The existing interface may be pants
but at least the name is pretty explicit that it will block. I think
this should then be easy enough to sort out in a backward compatible
manner in 4.3 since I expect the name of the function would change and
we could retain the old name in terms of the new for compat.

> ]   int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
> ]   int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num, 
> libxl_console_type type);
> ]   /* libxl_primary_console_exec finds the domid and console number
> ]    * corresponding to the primary console of the given vm, then calls
> ]    * libxl_console_exec with the right arguments (domid might be different
> ]    * if the guest is using stubdoms).
> ]    * This function can be called after creating the device model, in
> ]    * case of HVM guests, and before libxl_run_bootloader in case of PV
> ]    * guests using pygrub. */
> ]   int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm);
> 
> These functions should not exec things for you; they should tell you
> the parameters.  Any execing helpers should be in libxlu.

It's not enough for them to just use libxl__exec?

It'd be reasonably easy to make this return a libxl_string_list or
similar and to write a libxlu function which takes one of those.

> ]   /* common paths */
> ]   const char *libxl_sbindir_path(void);
> ]   const char *libxl_bindir_path(void);
> ]   const char *libxl_libexec_path(void);
> ]   const char *libxl_libdir_path(void);
> ]   const char *libxl_sharedir_path(void);
> ]   const char *libxl_private_bindir_path(void);
> ]   const char *libxl_xenfirmwaredir_path(void);
> ]   const char *libxl_xen_config_dir_path(void);
> ]   const char *libxl_xen_script_dir_path(void);
> ]   const char *libxl_lock_dir_path(void);
> ]   const char *libxl_run_dir_path(void);
> ]   const char *libxl_xenpaging_dir_path(void);
> 
> Surely these should be private ?

As far as I can grep, yes.

> Need to be ao/eventified:
> =========================
> 
> ]   typedef struct {
> ]   #define XL_SUSPEND_DEBUG 1
> ]   #define XL_SUSPEND_LIVE 2
> ]       int flags;
> ]       int (*suspend_callback)(void *, int);
> ]   } libxl_domain_suspend_info;
> ...
> ]   int libxl_domain_suspend(libxl_ctx *ctx, libxl_domain_suspend_info *info,
> ]                            uint32_t domid, int fd);
> 
> ]   typedef int (*libxl_console_ready)(libxl_ctx *ctx, uint32_t domid, void 
> *priv);
> ]   int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config 
> *d_config, libxl_console_ready cb, void *priv, uint32_t *domid);
> ]   int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config 
> *d_config, libxl_console_ready cb, void *priv, uint32_t *domid, int 
> restore_fd);

You are on the case with these?

> ]   int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
> 
> Are these now merely initiations ?

I think so yes.

Does a non-transaction write make a function "slow"? That's all these
actually do. If they are currently "fast" then we could likely get away
with a dummy ao_how. (I think it is valid for a function which is "fast"
to take an ao_how and always run sync?)

> ]   int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid, const char 
> *filename);
> 
> Might become long-running in the future.

But is currently fast? Dummy ao_how?

> ]   int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid, 
> libxl_device_disk *disk);

Roger makes this async in his hotplug series.

> ]   /*
> ]    * Insert a CD-ROM device. A device corresponding to disk must already
> ]    * be attached to the guest.
> ]    */
> ]   int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk 
> *disk);

Were you looking at this one? I know you mentioned it at one point.

> ]   /*
> ]    * Make a disk available in this (the control) domain. Returns path to
> ]    * a device.
> ]    */
> ]   char * libxl_device_disk_local_attach(libxl_ctx *ctx, libxl_device_disk 
> *disk);
> ]   int libxl_device_disk_local_detach(libxl_ctx *ctx, libxl_device_disk 
> *disk);
> 
> Does this even need to be public at this stage ?

I think Stefano internalises them in his qdisk/dom0-attach series.

> ]   /* Network Interfaces */
> ]   int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid, libxl_device_nic 
> *nic);
> 
> ]   /* Keyboard */
> ]   int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb 
> *vkb);
> 
> ]   /* Framebuffer */
> ]   int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vfb 
> *vfb);

These ought to be pretty trivial conversions?

> ]   /* PCI Passthrough */
> ]   int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid, libxl_device_pci 
> *pcidev);
> ]   int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid, 
> libxl_device_pci *pcidev);

I'm less confident that this one will be trivial to make async :-(

> ]   typedef struct libxl__xen_console_reader libxl_xen_console_reader;
> ]
> ]   libxl_xen_console_reader *
> ]       libxl_xen_console_read_start(libxl_ctx *ctx, int clear);
> ]   int libxl_xen_console_read_line(libxl_ctx *ctx,
> ]                                   libxl_xen_console_reader *cr,
> ]                                   char **line_r);
> ]   void libxl_xen_console_read_finish(libxl_ctx *ctx,
> ]                                      libxl_xen_console_reader *cr);

This is basically "xl dmesg". I'm not sure what interface makes sense
here, really it is just dumping the current ring, so each call is
"fast".

I'm not sure there is a need for an event driven "new-line-in-log"
callback style thing, i.e. a need to implement a "tail -f" style thing. 
Firstly I'm not sure that Xen actually produces an event which would
allow this to be implemented without polling and secondly if you want
that you can configure xenconsoled to log the hypervisor output and then
tail the logfile.

Perhaps this interface is OK?

> ]   char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long);
> ]   int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_destroy(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid);
> ]   int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name,
> ]                      uint32_t set);
> ]   int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid, char* uuid,
> ]                              int auth);
> ]   int libxl_tmem_freeable(libxl_ctx *ctx);
> 
> Not sure about the tmem calls.

Me neither.

> And from libxl_utils.h:
> 
> ]   pid_t libxl_fork(libxl_ctx *ctx);
> 
> This function is going to have to go away.

Great.

Maybe things aren't as bad as I feared.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel