* Outreachy golang bindings planning
@ 2016-10-12 11:49 George Dunlap
2016-10-17 17:15 ` Ronald Rojas
0 siblings, 1 reply; 4+ messages in thread
From: George Dunlap @ 2016-10-12 11:49 UTC (permalink / raw)
To: Ronald Rojas; +Cc: xen-devel
Hey Ronald,
My ultimate vision for the libxl golang project is to have the following:
- Golang bindings for all core libxl functionality
- A test program which exersises as much of that functionality as is
reasonable
The C libxl library has two components: parts that are written by hand
(such as libxl.h and libxl_*.c), and parts that are generated
programmatically by the IDL compiler (such as _libxl_types.h and
_libxl_types.c). I think the end goal should be to extend the IDL to
generate at least the Golang types, and probably a lot of the "helper"
methods as well (such as ${TYPE}.String() or ${TYPE}.FromString()).
But before diving into the I think it makes sense to first implement a
core set of functionality by hand, to see what the shape of the library
looks like, then implement the type-generation part of the IDL. Other
things we might do with the IDL, such as generation of utility methods,
we can add in at later points as well.
At the bottom of this mail, I've got all the libxl functions from
libxl.h sorted into what seems to me a useful order to start working on
things.
I list here the "headers". This is a *lot* of functionality; I very
greatly doubt that it will be possible to get all of it implemented and
tested during the internship. I'd much rather have a decent core set of
functionality with a really good testing than attempt to get all the
functions "implemented" in a way which nobody knows if it works.
If we can get the basic IDL working, and stuff implemented and
well-tested through "Secondary host operations", I think the internship
will have been a solid success. If we get through "Devices: PCI", I
think it will have been a wild success. :-)
Thanks,
-George
---
(Headers only)
# Libxl and host-related functionality
# Primary domain operations: Create / shutdown / destroy
(This will probably take a fairly large chunk of time to, as we run
across most of the design / architectural decisions with the bindings.
And at the end you'll only be able to start VMs with no devices!)
# Devices: Disk
# Devices: Network
(At this point, we have the core VM functionality.)
# Secondary domain operations: manipulate, suspend / resume / reset
# Secondary host operations
# More domain operations
# Advanced host config
# Devices: USB
# Devices: PCI
# Devices: VFB
# Devices: Channels
# Advanced domain config
# Devices: VKB
# Devices: VTPM
# PSR
# Flask
# Domain operations: Exec helper functions
# Miscellanious behavior
---
(Headers and functions)
# Libxl and host-related functionality
const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);
int libxl_get_max_cpus(libxl_ctx *ctx);
int libxl_get_online_cpus(libxl_ctx *ctx);
int libxl_get_max_nodes(libxl_ctx *ctx);
int libxl_get_free_memory(libxl_ctx *ctx, uint64_t *memkb);
int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);
# Primary domain operations: Create (with disk / network), shutdown /
destroy
int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
uint32_t *domid,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
uint32_t domid);
libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain_out);
libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
int *nb_vcpu, int *nr_cpus_out);
int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num,
libxl_console_type type, char **path);
int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
char **path);
# Devices: Disk
int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t
domid, int *num);
int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t domid,
libxl_device_disk *disk, libxl_diskinfo
*diskinfo);
int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk
*disk,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
# Devices: Network
int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_nic *nic,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_nic_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_nic *nic,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_nic_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_nic *nic,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
libxl_device_nic *libxl_device_nic_list(libxl_ctx *ctx, uint32_t domid,
int *num);
int libxl_device_nic_getinfo(libxl_ctx *ctx, uint32_t domid,
libxl_device_nic *nic, libxl_nicinfo
*nicinfo);
# Secondary domain operations: manipulate, suspend / resume / reset
int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
libxl_domain_create_info *info, const char *name_suffix, libxl_uuid
new_uuid);
int libxl_send_trigger(libxl_ctx *ctx, uint32_t domid,
libxl_trigger trigger, uint32_t vcpuid);
int libxl_send_sysrq(libxl_ctx *ctx, uint32_t domid, char sysrq);
int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint64_t
target_memkb);
int libxl_get_memory_target(libxl_ctx *ctx, uint32_t domid, uint64_t
*out_target);
int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, int64_t
target_memkb, int relative, int enforce);
int libxl_wait_for_memory_target(libxl_ctx *ctx, uint32_t domid, int
wait_secs);
int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config
*d_config,
uint32_t *domid, int restore_fd,
int send_back_fd,
const libxl_domain_restore_params *params,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how
*aop_console_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_suspend(libxl_ctx *ctx, uint32_t domid, int fd,
int flags, /* LIBXL_SUSPEND_* */
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_resume(libxl_ctx *ctx, uint32_t domid, int suspend_cancel,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
// HVM-only kexec
int libxl_domain_soft_reset(libxl_ctx *ctx,
libxl_domain_config *d_config,
uint32_t domid,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how
*aop_console_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_rename(libxl_ctx *ctx, uint32_t domid,
const char *old_name, const char *new_name);
/* if old_name is NULL, any old name is OK; otherwise we check
* transactionally that the domain has the old old name; if
* trans is not 0 we use caller's transaction and caller must do
retries */
# Secondary host operations
libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain_out);
libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out);
libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool_out);
libxl_cputopology *libxl_get_cpu_topology(libxl_ctx *ctx, int *nb_cpu_out);
libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr);
libxl_pcitopology *libxl_get_pci_topology(libxl_ctx *ctx, int *num_devs);
# More domain operations
int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
const libxl_bitmap *cpumap_hard,
const libxl_bitmap *cpumap_soft);
int libxl_set_vcpuaffinity_force(libxl_ctx *ctx, uint32_t domid,
uint32_t vcpuid,
const libxl_bitmap *cpumap_hard,
const libxl_bitmap *cpumap_soft);
int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
unsigned int max_vcpus,
const libxl_bitmap *cpumap_hard,
const libxl_bitmap *cpumap_soft);
int libxl_domain_set_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
libxl_bitmap *nodemap);
int libxl_domain_get_nodeaffinity(libxl_ctx *ctx, uint32_t domid,
libxl_bitmap *nodemap);
int libxl_set_vcpuonline(libxl_ctx *ctx, uint32_t domid, libxl_bitmap
*cpumap);
int libxl_domain_sched_params_get(libxl_ctx *ctx, uint32_t domid,
libxl_domain_sched_params *params);
int libxl_domain_sched_params_set(libxl_ctx *ctx, uint32_t domid,
const libxl_domain_sched_params *params);
int libxl_vcpu_sched_params_get(libxl_ctx *ctx, uint32_t domid,
libxl_vcpu_sched_params *params);
int libxl_vcpu_sched_params_get_all(libxl_ctx *ctx, uint32_t domid,
libxl_vcpu_sched_params *params);
int libxl_vcpu_sched_params_set(libxl_ctx *ctx, uint32_t domid,
const libxl_vcpu_sched_params *params);
int libxl_vcpu_sched_params_set_all(libxl_ctx *ctx, uint32_t domid,
const libxl_vcpu_sched_params *params);
# Advanced host config
int libxl_get_scheduler(libxl_ctx *ctx);
int libxl_sched_credit_params_get(libxl_ctx *ctx, uint32_t poolid,
libxl_sched_credit_params *scinfo);
int libxl_sched_credit_params_set(libxl_ctx *ctx, uint32_t poolid,
libxl_sched_credit_params *scinfo);
int libxl_sched_credit2_params_get(libxl_ctx *ctx, uint32_t poolid,
libxl_sched_credit2_params *scinfo);
int libxl_sched_credit2_params_set(libxl_ctx *ctx, uint32_t poolid,
libxl_sched_credit2_params *scinfo);
int libxl_send_debug_keys(libxl_ctx *ctx, char *keys);
int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
libxl_scheduler sched,
libxl_bitmap cpumap, libxl_uuid *uuid,
uint32_t *poolid);
int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
int libxl_cpupool_rename(libxl_ctx *ctx, const char *name, uint32_t poolid);
int libxl_cpupool_cpuadd(libxl_ctx *ctx, uint32_t poolid, int cpu);
int libxl_cpupool_cpuadd_node(libxl_ctx *ctx, uint32_t poolid, int node,
int *cpus);
int libxl_cpupool_cpuadd_cpumap(libxl_ctx *ctx, uint32_t poolid,
const libxl_bitmap *cpumap);
int libxl_cpupool_cpuremove(libxl_ctx *ctx, uint32_t poolid, int cpu);
int libxl_cpupool_cpuremove_node(libxl_ctx *ctx, uint32_t poolid, int
node, int *cpus);
int libxl_cpupool_cpuremove_cpumap(libxl_ctx *ctx, uint32_t poolid,
const libxl_bitmap *cpumap);
int libxl_cpupool_movedomain(libxl_ctx *ctx, uint32_t poolid, uint32_t
domid);
int libxl_cpupool_info(libxl_ctx *ctx, libxl_cpupoolinfo *info, uint32_t
poolid);
# Devices: USB
int libxl_device_usbctrl_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_usbctrl *usbctrl,
const libxl_asyncop_how *ao_how)
int libxl_device_usbctrl_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_usbctrl *usbctrl,
const libxl_asyncop_how *ao_how)
int libxl_device_usbctrl_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_usbctrl *usbctrl,
const libxl_asyncop_how *ao_how)
libxl_device_usbctrl *libxl_device_usbctrl_list(libxl_ctx *ctx,
uint32_t domid, int *num);
int libxl_device_usbctrl_getinfo(libxl_ctx *ctx, uint32_t domid,
libxl_device_usbctrl *usbctrl,
libxl_usbctrlinfo *usbctrlinfo);
int libxl_device_usbdev_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_usbdev *usbdev,
const libxl_asyncop_how *ao_how)
int libxl_device_usbdev_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_usbdev *usbdev,
const libxl_asyncop_how *ao_how)
libxl_device_usbdev *
libxl_device_usbdev_list(libxl_ctx *ctx, uint32_t domid, int *num);
# PCI
int libxl_device_pci_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_pci *pcidev,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_pci_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_pci *pcidev,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_pci_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_pci *pcidev,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
libxl_device_pci *libxl_device_pci_list(libxl_ctx *ctx, uint32_t domid,
int *num);
int libxl_device_pci_assignable_add(libxl_ctx *ctx, libxl_device_pci
*pcidev, int rebind);
int libxl_device_pci_assignable_remove(libxl_ctx *ctx, libxl_device_pci
*pcidev, int rebind);
libxl_device_pci *libxl_device_pci_assignable_list(libxl_ctx *ctx, int
*num);
# Devices: VFB
int libxl_device_vfb_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vfb *vfb,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_vfb_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_vfb *vfb,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_vfb_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_vfb *vfb,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
# Devices: Channels
libxl_device_channel *libxl_device_channel_list(libxl_ctx *ctx,
uint32_t domid,
int *num);
int libxl_device_channel_getinfo(libxl_ctx *ctx, uint32_t domid,
libxl_device_channel *channel,
libxl_channelinfo *channelinfo);
# Advanced domain config
int libxl_userdata_store(libxl_ctx *ctx, uint32_t domid,
const char *userdata_userid,
const uint8_t *data, int datalen);
int libxl_userdata_retrieve(libxl_ctx *ctx, uint32_t domid,
const char *userdata_userid,
uint8_t **data_r, int *datalen_r);
int libxl_userdata_unlink(libxl_ctx *ctx, uint32_t domid,
const char *userdata_userid);
void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid);
void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid,
libxl_cpuid_policy_list cpuid);
int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
const char *command_line, char **output);
# Devices: VKB
int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vkb *vkb,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_vkb_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_vkb *vkb,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_vkb_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_vkb *vkb,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
# Devices: VTPM
int libxl_device_vtpm_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_vtpm_remove(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_vtpm_destroy(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t
domid, int *num);
int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
libxl_device_vtpm *vtpm, libxl_vtpminfo
*vtpminfo);
# PSR
int libxl_psr_cmt_attach(libxl_ctx *ctx, uint32_t domid);
int libxl_psr_cmt_detach(libxl_ctx *ctx, uint32_t domid);
int libxl_psr_cmt_domain_attached(libxl_ctx *ctx, uint32_t domid);
int libxl_psr_cmt_enabled(libxl_ctx *ctx);
int libxl_psr_cmt_get_total_rmid(libxl_ctx *ctx, uint32_t *total_rmid);
int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx,
uint32_t socketid,
uint32_t *l3_cache_size);
int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx,
uint32_t domid,
uint32_t socketid,
uint32_t *l3_cache_occupancy);
int libxl_psr_cmt_type_supported(libxl_ctx *ctx, libxl_psr_cmt_type type);
int libxl_psr_cmt_get_sample(libxl_ctx *ctx,
uint32_t domid,
libxl_psr_cmt_type type,
uint64_t scope,
uint64_t *sample_r,
uint64_t *tsc_r);
int libxl_psr_cat_set_cbm(libxl_ctx *ctx, uint32_t domid,
libxl_psr_cbm_type type, libxl_bitmap *target_map,
uint64_t cbm);
int libxl_psr_cat_get_cbm(libxl_ctx *ctx, uint32_t domid,
libxl_psr_cbm_type type, uint32_t target,
uint64_t *cbm_r);
int libxl_psr_cat_get_l3_info(libxl_ctx *ctx, libxl_psr_cat_info **info,
int *nr);
void libxl_psr_cat_info_list_free(libxl_psr_cat_info *list, int nr);
# Flask
int libxl_flask_context_to_sid(libxl_ctx *ctx, char *buf, size_t len,
uint32_t *ssidref);
int libxl_flask_sid_to_context(libxl_ctx *ctx, uint32_t ssidref, char **buf,
size_t *len);
int libxl_flask_getenforce(libxl_ctx *ctx);
int libxl_flask_setenforce(libxl_ctx *ctx, int mode);
int libxl_flask_loadpolicy(libxl_ctx *ctx, void *policy, uint32_t size);
# Domain operations: Exec helper functions
int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
libxl_console_type type, int notify_fd);
int libxl_primary_console_exec(libxl_ctx *ctx, uint32_t domid_vm,
int notify_fd);
int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t domid, int autopass);
# Miscellanious behavior
int libxl_ms_vm_genid_generate(libxl_ctx *ctx, libxl_ms_vm_genid *id);
bool libxl_ms_vm_genid_is_zero(const libxl_ms_vm_genid *id);
void libxl_ms_vm_genid_copy(libxl_ctx *ctx, libxl_ms_vm_genid *dst,
const libxl_ms_vm_genid *src);
int libxl_device_events_handler(libxl_ctx *ctx,
const libxl_asyncop_how *ao_how)
int libxl_domain_core_dump(libxl_ctx *ctx, uint32_t domid,
const char *filename,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
uint32_t domid, int send_fd, int recv_fd,
const libxl_asyncop_how *ao_how)
LIBXL_EXTERNAL_CALLERS_ONLY;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Outreachy golang bindings planning
2016-10-12 11:49 Outreachy golang bindings planning George Dunlap
@ 2016-10-17 17:15 ` Ronald Rojas
2016-11-11 12:42 ` Lars Kurth
0 siblings, 1 reply; 4+ messages in thread
From: Ronald Rojas @ 2016-10-17 17:15 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel
On Wed, Oct 12, 2016 at 12:49:18PM +0100, George Dunlap wrote:
> Hey Ronald,
>
> My ultimate vision for the libxl golang project is to have the following:
>
> - Golang bindings for all core libxl functionality
> - A test program which exersises as much of that functionality as is
> reasonable
>
> The C libxl library has two components: parts that are written by hand
> (such as libxl.h and libxl_*.c), and parts that are generated
> programmatically by the IDL compiler (such as _libxl_types.h and
> _libxl_types.c). I think the end goal should be to extend the IDL to
> generate at least the Golang types, and probably a lot of the "helper"
> methods as well (such as ${TYPE}.String() or ${TYPE}.FromString()).
>
> But before diving into the I think it makes sense to first implement a
> core set of functionality by hand, to see what the shape of the library
> looks like, then implement the type-generation part of the IDL. Other
> things we might do with the IDL, such as generation of utility methods,
> we can add in at later points as well.
>
> At the bottom of this mail, I've got all the libxl functions from
> libxl.h sorted into what seems to me a useful order to start working on
> things.
>
> I list here the "headers". This is a *lot* of functionality; I very
> greatly doubt that it will be possible to get all of it implemented and
> tested during the internship. I'd much rather have a decent core set of
> functionality with a really good testing than attempt to get all the
> functions "implemented" in a way which nobody knows if it works.
>
> If we can get the basic IDL working, and stuff implemented and
> well-tested through "Secondary host operations", I think the internship
> will have been a solid success. If we get through "Devices: PCI", I
> think it will have been a wild success. :-)
>
It looks like due to the large timezone difference that we have I'm not able to
catch you on #xen-devel a lot of the time so I may start relying on email
a bit more, anyway...
I made a quick timeline in a google doc that outlines what I think I can
accomplish during the duration of the Outreachy internship which I will link
below(1). I gave it a fairly optimistic view of what could be done so that if
anything happens, like an emergency or maybe something is harder then expected,
enough should still be accomplished during the internship period so that it'll
still be considered a success. Feel free to edit it however you want.
Since the application would have been due later today, October 17 7:00PM UTC,
I tentatively submitted the application. It can be edited until November 8th
so if you think I should change anything let me know and I'll do that as soon
as I can. I'm not sure if you can view my application now but I will provide
a link to a google doc that will have exactly what I submitted on my
application(2). You should be able to edit it if you want to.
Notes on school:
I have most of my midterms next week so I probably won't be able to contribute
much then. I will try to finish all of the major problems this week, like
finalizing the application and the project timeline. Then in two weeks I will
have the time to do some more work, like creating the Makefile for the golang
binding project.
Links:
(1) https://docs.google.com/document/d/1X1Xyb8YBGcBsfDH1oDsUPQM8lwCLYrJQmgV52HStY6o/edit?usp=sharing
(2) https://docs.google.com/document/d/1yfVc5eJlIeQYiccuvu6YMLUm4_uGJOypOYjM_zmd6HQ/edit?usp=sharing
Thanks,
Ronald Rojas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Outreachy golang bindings planning
2016-10-17 17:15 ` Ronald Rojas
@ 2016-11-11 12:42 ` Lars Kurth
2016-11-14 12:21 ` Ronald Rojas
0 siblings, 1 reply; 4+ messages in thread
From: Lars Kurth @ 2016-11-11 12:42 UTC (permalink / raw)
To: Ronald Rojas; +Cc: George Dunlap, xen-devel
Ronald,
I am not sure whether you checked the Outreachy page and apologies for getting back late, but this project has been accepted. Let me know of your own blog and whether you'd be willing to write a guest blog or let me cover a quick blog on blog.xenproject.org as an introduction to the community. I would need a few sentences about yourself, what motivates you, what you are trying to achieve though.
Best Regards
Lars
> On 17 Oct 2016, at 18:15, Ronald Rojas <ronladred@gmail.com> wrote:
>
> On Wed, Oct 12, 2016 at 12:49:18PM +0100, George Dunlap wrote:
>> Hey Ronald,
>>
>> My ultimate vision for the libxl golang project is to have the following:
>>
>> - Golang bindings for all core libxl functionality
>> - A test program which exersises as much of that functionality as is
>> reasonable
>>
>> The C libxl library has two components: parts that are written by hand
>> (such as libxl.h and libxl_*.c), and parts that are generated
>> programmatically by the IDL compiler (such as _libxl_types.h and
>> _libxl_types.c). I think the end goal should be to extend the IDL to
>> generate at least the Golang types, and probably a lot of the "helper"
>> methods as well (such as ${TYPE}.String() or ${TYPE}.FromString()).
>>
>> But before diving into the I think it makes sense to first implement a
>> core set of functionality by hand, to see what the shape of the library
>> looks like, then implement the type-generation part of the IDL. Other
>> things we might do with the IDL, such as generation of utility methods,
>> we can add in at later points as well.
>>
>> At the bottom of this mail, I've got all the libxl functions from
>> libxl.h sorted into what seems to me a useful order to start working on
>> things.
>>
>> I list here the "headers". This is a *lot* of functionality; I very
>> greatly doubt that it will be possible to get all of it implemented and
>> tested during the internship. I'd much rather have a decent core set of
>> functionality with a really good testing than attempt to get all the
>> functions "implemented" in a way which nobody knows if it works.
>>
>> If we can get the basic IDL working, and stuff implemented and
>> well-tested through "Secondary host operations", I think the internship
>> will have been a solid success. If we get through "Devices: PCI", I
>> think it will have been a wild success. :-)
>>
>
> It looks like due to the large timezone difference that we have I'm not able to
> catch you on #xen-devel a lot of the time so I may start relying on email
> a bit more, anyway...
>
> I made a quick timeline in a google doc that outlines what I think I can
> accomplish during the duration of the Outreachy internship which I will link
> below(1). I gave it a fairly optimistic view of what could be done so that if
> anything happens, like an emergency or maybe something is harder then expected,
> enough should still be accomplished during the internship period so that it'll
> still be considered a success. Feel free to edit it however you want.
>
> Since the application would have been due later today, October 17 7:00PM UTC,
> I tentatively submitted the application. It can be edited until November 8th
> so if you think I should change anything let me know and I'll do that as soon
> as I can. I'm not sure if you can view my application now but I will provide
> a link to a google doc that will have exactly what I submitted on my
> application(2). You should be able to edit it if you want to.
>
> Notes on school:
> I have most of my midterms next week so I probably won't be able to contribute
> much then. I will try to finish all of the major problems this week, like
> finalizing the application and the project timeline. Then in two weeks I will
> have the time to do some more work, like creating the Makefile for the golang
> binding project.
>
> Links:
> (1) https://docs.google.com/document/d/1X1Xyb8YBGcBsfDH1oDsUPQM8lwCLYrJQmgV52HStY6o/edit?usp=sharing
> (2) https://docs.google.com/document/d/1yfVc5eJlIeQYiccuvu6YMLUm4_uGJOypOYjM_zmd6HQ/edit?usp=sharing
>
> Thanks,
> Ronald Rojas
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Outreachy golang bindings planning
2016-11-11 12:42 ` Lars Kurth
@ 2016-11-14 12:21 ` Ronald Rojas
0 siblings, 0 replies; 4+ messages in thread
From: Ronald Rojas @ 2016-11-14 12:21 UTC (permalink / raw)
To: Lars Kurth; +Cc: George Dunlap, xen-devel
On Fri, Nov 11, 2016 at 12:42:52PM +0000, Lars Kurth wrote:
> Ronald,
> I am not sure whether you checked the Outreachy page and apologies for getting back late, but this project has been accepted. Let me know of your own blog and whether you'd be willing to write a guest blog or let me cover a quick blog on blog.xenproject.org as an introduction to the community. I would need a few sentences about yourself, what motivates you, what you are trying to achieve though.
Hi Lars,
I just found out I was accepted to the outreachy program a few days ago, so
thanks Lars and George for accepting the project! I don't have a blog but I
know that the outreachy program reccomends a blog for the program. I will
probably be setting up a wordpress site in the next few days and will let you
know when I get that done.
For the Xen Project blog you can use the following:
I'm a 3rd year student at New York University studying computer science. I'm
also from New York City so New York has always been my home. This will be my
first time working in a FOSS project and I'm really looking forward to it.
When I first started applying to outreachy was when I first learned
about Xen. I thought the idea was really cool and it's something that I was
already interested in so I decided to put my efforts into this project. What I
wanted from this project was a good way to get involved with open source
projects and to start contibuting. Once the internship is over I think I will
try to complete my project andd try to contribute to xen in other areas as
well.
Feel free to paraphase what I wrote or let me know if you need more
information.
Ronald Rojas
>
> > On 17 Oct 2016, at 18:15, Ronald Rojas <ronladred@gmail.com> wrote:
> >
> > On Wed, Oct 12, 2016 at 12:49:18PM +0100, George Dunlap wrote:
> >> Hey Ronald,
> >>
> >> My ultimate vision for the libxl golang project is to have the following:
> >>
> >> - Golang bindings for all core libxl functionality
> >> - A test program which exersises as much of that functionality as is
> >> reasonable
> >>
> >> The C libxl library has two components: parts that are written by hand
> >> (such as libxl.h and libxl_*.c), and parts that are generated
> >> programmatically by the IDL compiler (such as _libxl_types.h and
> >> _libxl_types.c). I think the end goal should be to extend the IDL to
> >> generate at least the Golang types, and probably a lot of the "helper"
> >> methods as well (such as ${TYPE}.String() or ${TYPE}.FromString()).
> >>
> >> But before diving into the I think it makes sense to first implement a
> >> core set of functionality by hand, to see what the shape of the library
> >> looks like, then implement the type-generation part of the IDL. Other
> >> things we might do with the IDL, such as generation of utility methods,
> >> we can add in at later points as well.
> >>
> >> At the bottom of this mail, I've got all the libxl functions from
> >> libxl.h sorted into what seems to me a useful order to start working on
> >> things.
> >>
> >> I list here the "headers". This is a *lot* of functionality; I very
> >> greatly doubt that it will be possible to get all of it implemented and
> >> tested during the internship. I'd much rather have a decent core set of
> >> functionality with a really good testing than attempt to get all the
> >> functions "implemented" in a way which nobody knows if it works.
> >>
> >> If we can get the basic IDL working, and stuff implemented and
> >> well-tested through "Secondary host operations", I think the internship
> >> will have been a solid success. If we get through "Devices: PCI", I
> >> think it will have been a wild success. :-)
> >>
> >
> > It looks like due to the large timezone difference that we have I'm not able to
> > catch you on #xen-devel a lot of the time so I may start relying on email
> > a bit more, anyway...
> >
> > I made a quick timeline in a google doc that outlines what I think I can
> > accomplish during the duration of the Outreachy internship which I will link
> > below(1). I gave it a fairly optimistic view of what could be done so that if
> > anything happens, like an emergency or maybe something is harder then expected,
> > enough should still be accomplished during the internship period so that it'll
> > still be considered a success. Feel free to edit it however you want.
> >
> > Since the application would have been due later today, October 17 7:00PM UTC,
> > I tentatively submitted the application. It can be edited until November 8th
> > so if you think I should change anything let me know and I'll do that as soon
> > as I can. I'm not sure if you can view my application now but I will provide
> > a link to a google doc that will have exactly what I submitted on my
> > application(2). You should be able to edit it if you want to.
> >
> > Notes on school:
> > I have most of my midterms next week so I probably won't be able to contribute
> > much then. I will try to finish all of the major problems this week, like
> > finalizing the application and the project timeline. Then in two weeks I will
> > have the time to do some more work, like creating the Makefile for the golang
> > binding project.
> >
> > Links:
> > (1) https://docs.google.com/document/d/1X1Xyb8YBGcBsfDH1oDsUPQM8lwCLYrJQmgV52HStY6o/edit?usp=sharing
> > (2) https://docs.google.com/document/d/1yfVc5eJlIeQYiccuvu6YMLUm4_uGJOypOYjM_zmd6HQ/edit?usp=sharing
> >
> > Thanks,
> > Ronald Rojas
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-11-14 12:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-12 11:49 Outreachy golang bindings planning George Dunlap
2016-10-17 17:15 ` Ronald Rojas
2016-11-11 12:42 ` Lars Kurth
2016-11-14 12:21 ` Ronald Rojas
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.