New Outreachy Applicant

New Outreachy Applicant

[Ronald Rojas]

Hi, I'm Ronald Rojas an undergraduate junior studying 
computer science at New York Unversity. I would like
to apply fo the Xen projects Outreachy Program. After
looking through the available projects I think I would 
be a good fit for creating the golang bindings for 
libxl. I'm proficient in C , familar with Golang, and 
very comfortable with linux. Would I be able to get a 
bit-sized task for the application process? 

Thank you, 
Ronald Rojas


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

Re: New Outreachy Applicant

[George Dunlap]

[-- Attachment #1: Type: text/plain, Size: 3557 bytes --]

On Wed, Sep 14, 2016 at 7:35 AM, Ronald Rojas <ronladred@gmail.com> wrote:
> Hi, I'm Ronald Rojas an undergraduate junior studying
> computer science at New York Unversity. I would like
> to apply fo the Xen projects Outreachy Program. After
> looking through the available projects I think I would
> be a good fit for creating the golang bindings for
> libxl. I'm proficient in C , familar with Golang, and
> very comfortable with linux. Would I be able to get a
> bit-sized task for the application process?

Ronald,

Thanks for your interest in the Xen Project!  Sorry for the delay in
responding -- somehow your mail either never made it to my personal
inbox or I accidentally deleted it instead of filing it properly.  I
saw your question on IRC and now found your mail here on xen-devel.

First, I want to emphasize that Outreachy internships should be
considered a full-time job.  As part of the application process you
will be asked to confirm that you will not be taking any classes, nor
have any other significant commitments (such as another job) during
the period of the internship.

Now on to the bite-sized task.  We've actually found that one of the
difficult parts of getting going with our project is making sure that
you understand how to get your whole system and environment set up.
And another thing we want to see is to what degree you can balance
figuring things out, finding the answers on the web, and asking for
help when you need it.

So with that in mind, we've started experimenting with tasks which
don't contribute very much to the project directly, but provide a
really solid base of knowledge to do further contributions.

So here's my challenge for you.

-------
OUTCOME

Attached is the very beginnings of a set of golang bindings that I
wrote for a project of my own.  They contain an implementation of
Context.Open() and Context.ListCpupool().

Write a simple go program that will list the current cpu pools,
similar to the output of "xl cpupool-list".  No need to handle extra
arguments or modify libxl.go (beyond what may be needed to compile it).

Please post a copy of your .go program, along with the results of
output *when more than one VM is running*.

STEPS

1. Set up a system running Linux

If you don't have one, Ubuntu, Fedora, or Debian should all be fine.

2. Download, build, and install the latest development
version of Xen.  The following page should be useful:

https://wiki.xenproject.org/wiki/Compiling_Xen_From_Source

I would recommend using "make debball" or "make rpmball" over the
"make install".

3. You'll need to build an image for at least one guest VM.

There are tons of options here, but one really simple thing would be
to follow this HOWTO from a previous OPW intern:

https://umasharma17.wordpress.com/2015/02/13/creating-guests-using-xl-in-xen/

4. Write your go program

The go program will need to Open() the context, then call DomainInfo()
on the target domain ID, and output the required info based on "xl
list".

libxl.go uses cgo to compile a library against C.  If you have the
libraries set up properly, the current version should just work.

------

That's it!  Remember that the goal of this is to see how well you
balance figuring things out on your own vs asking questions.  So try
to figure things out on your own, but when you run into a bit of
difficultly, don't hesitate to ask questions or clarification --
particularly at the beginning.

You can ask questions either here on xen-devel or on the #xendevel or
#xen-opw channels on freenode IRC.

Good luck,
 -George

[-- Attachment #2: libxl.go --]
[-- Type: text/x-go, Size: 6286 bytes --]

/*
 * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; version 2 of the
 * License only.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 * 02110-1301, USA.
 */
package main

/*
#cgo LDFLAGS: -lyajl -lxenlight
#include <libxl.h>
#include <stdlib.h>
*/
import "C"

import (
	"unsafe"
	"fmt"
	"time"
)

type Context struct {
	ctx *C.libxl_ctx
}

var Ctx Context

func (Ctx *Context) IsOpen() bool {
	return Ctx.ctx != nil
}

func (Ctx *Context) Open() (err error) {
	if Ctx.ctx != nil {
		return
	}
	
	ret := C.libxl_ctx_alloc(unsafe.Pointer(&Ctx.ctx), C.LIBXL_VERSION, 0, nil)

	if ret != 0 {
		err = fmt.Errorf("Allocating libxl context: %d", ret)
	}
	return
}

func (Ctx *Context) Close() (err error) {
	ret := C.libxl_ctx_free(unsafe.Pointer(Ctx.ctx))
	Ctx.ctx = nil

	if ret != 0 {
		err = fmt.Errorf("Freeing libxl context: %d", ret)
	}
	return
}

type Domid uint32

type MemKB uint64

// FIXME: Use the idl to generate types
type Dominfo struct {
	// FIXME: uuid
	Domid             Domid
	Running           bool
	Blocked           bool
	Paused            bool
	Shutdown          bool
	Dying             bool
	Never_stop        bool
	
	Shutdown_reason   int32 // FIXME shutdown_reason enumeration
	Outstanding_memkb MemKB
	Current_memkb     MemKB
	Shared_memkb      MemKB
	Paged_memkb       MemKB
	Max_memkb         MemKB
	Cpu_time          time.Duration
	Vcpu_max_id       uint32
	Vcpu_online       uint32
	Cpupool           uint32
	Domain_type       int32 //FIXME libxl_domain_type enumeration

}

func (Ctx *Context) DomainInfo(Id Domid) (di *Dominfo, err error) {
	if Ctx.ctx == nil {
		err = fmt.Errorf("Context not opened")
		return
	}

		
	var cdi C.libxl_dominfo

	ret := C.libxl_domain_info(Ctx.ctx, unsafe.Pointer(&cdi), C.uint32_t(Id))

	// FIXME: IsDomainNotPresentError
	if ret != 0 {
		err = fmt.Errorf("libxl_domain_info failed: %d", ret)
		return
	}

	// FIXME -- use introspection to make this more robust
	di = &Dominfo{}
	di.Domid = Domid(cdi.domid)
	di.Running = bool(cdi.running)
	di.Blocked = bool(cdi.blocked)
	di.Paused = bool(cdi.paused)
	di.Shutdown = bool(cdi.shutdown)
	di.Dying = bool(cdi.dying)
	di.Never_stop = bool(cdi.never_stop)
	di.Shutdown_reason = int32(cdi.shutdown_reason)
	di.Outstanding_memkb = MemKB(cdi.outstanding_memkb)
	di.Current_memkb = MemKB(cdi.current_memkb)
	di.Shared_memkb = MemKB(cdi.shared_memkb)
	di.Paged_memkb = MemKB(cdi.paged_memkb)
	di.Max_memkb = MemKB(cdi.max_memkb)
	di.Cpu_time = time.Duration(cdi.cpu_time)
	di.Vcpu_max_id = uint32(cdi.vcpu_max_id)
	di.Vcpu_online = uint32(cdi.vcpu_online)
	di.Cpupool = uint32(cdi.cpupool)
	di.Domain_type = int32(cdi.domain_type)
	return
}

func (Ctx *Context) DomainUnpause(Id Domid) (err error) {
	if Ctx.ctx == nil {
		err = fmt.Errorf("Context not opened")
		return
	}

	ret := C.libxl_domain_unpause(Ctx.ctx, C.uint32_t(Id))

	if ret != 0 {
		err = fmt.Errorf("libxl_domain_unpause failed: %d", ret)
	}
	return
}


// typedef struct {
//     uint32_t size;          /* number of bytes in map */
//     uint8_t *map;
// } libxl_bitmap;
// void libxl_bitmap_init(libxl_bitmap *map);
// void libxl_bitmap_dispose(libxl_bitmap *map);

// # Consistent with values defined in domctl.h
// # Except unknown which we have made up
// libxl_scheduler = Enumeration("scheduler", [
//     (0, "unknown"),
//     (4, "sedf"),
//     (5, "credit"),
//     (6, "credit2"),
//     (7, "arinc653"),
//     (8, "rtds"),
//     ])
type Scheduler int
var (
	SchedulerUnknown  Scheduler = 0
	SchedulerSedf     Scheduler = 4
	SchedulerCredit   Scheduler = 5
	SchedulerCredit2  Scheduler = 6
	SchedulerArinc653 Scheduler = 7
	SchedulerRTDS     Scheduler = 8
)

// const char *libxl_scheduler_to_string(libxl_scheduler p);
// int libxl_scheduler_from_string(const char *s, libxl_scheduler *e);
func (s Scheduler) String() (string) {
	cs := C.libxl_scheduler_to_string(C.libxl_scheduler(s))
	// No need to free const return value

	return C.GoString(cs)
}

func SchedulerFromString(name string) (s Scheduler, err error) {
	cname := C.CString(name)
	defer C.free(unsafe.Pointer(cname))

	var cs C.libxl_scheduler

	ret := C.libxl_scheduler_from_string(cname, &cs)
	if ret != 0 {
		err = fmt.Errorf("libxl_scheduler_from_string failed: %d", ret)
		return
	}

	s = Scheduler(cs)

	return
}

// libxl_cpupoolinfo = Struct("cpupoolinfo", [
//     ("poolid",      uint32),
//     ("pool_name",   string),
//     ("sched",       libxl_scheduler),
//     ("n_dom",       uint32),
//     ("cpumap",      libxl_bitmap)
//     ], dir=DIR_OUT)

type CpupoolInfo struct {
	PoolId uint32
	PoolName string
	Scheduler Scheduler
	DomainCount int
	// Punt on cpumap for now
}

// libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool_out);
// void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nb_pool);
func (Ctx *Context) ListCpupool() (list []CpupoolInfo) {
	var nbPool C.int

	c_cpupool_list := C.libxl_list_cpupool(Ctx.ctx, &nbPool)

	defer C.libxl_cpupoolinfo_list_free(c_cpupool_list, nbPool)

	if int(nbPool) == 0 {
		return
	}

	// Magic
	cpupoolListSlice := (*[1 << 30]C.libxl_cpupoolinfo)(unsafe.Pointer(c_cpupool_list))[:nbPool:nbPool]

	for i := range cpupoolListSlice {
		var info CpupoolInfo
		
		info.PoolId = uint32(cpupoolListSlice[i].poolid)
		info.PoolName = C.GoString(cpupoolListSlice[i].pool_name)
		info.Scheduler = Scheduler(cpupoolListSlice[i].sched)
		info.DomainCount = int(cpupoolListSlice[i].n_dom)

		list = append(list, info)
	}

	return
}

func (Ctx *Context) CpupoolFindByName(name string) (info CpupoolInfo, found bool) {
	plist := Ctx.ListCpupool()

	for i := range plist {
		if plist[i].PoolName == name {
			found = true
			info = plist[i]
			return
		}
	}
	return
}

[-- Attachment #3: Type: text/plain, Size: 127 bytes --]

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

Re: New Outreachy Applicant

[Ronald Rojas]

[-- Attachment #1: Type: text/plain, Size: 3455 bytes --]

On Tue, Sep 20, 2016 at 04:24:47PM +0100, George Dunlap wrote:
> Thanks for your interest in the Xen Project!  Sorry for the delay in
> responding -- somehow your mail either never made it to my personal
> inbox or I accidentally deleted it instead of filing it properly.  I
> saw your question on IRC and now found your mail here on xen-devel.
> 
> First, I want to emphasize that Outreachy internships should be
> considered a full-time job.  As part of the application process you
> will be asked to confirm that you will not be taking any classes, nor
> have any other significant commitments (such as another job) during
> the period of the internship.

I'll confirm now that won't be taking any classes or working during the
majority of the program, however the fall semester for my college will
end around the 20th of December. 
> 
> Now on to the bite-sized task.  We've actually found that one of the
> difficult parts of getting going with our project is making sure that
> you understand how to get your whole system and environment set up.
> And another thing we want to see is to what degree you can balance
> figuring things out, finding the answers on the web, and asking for
> help when you need it.
> 
> So with that in mind, we've started experimenting with tasks which
> don't contribute very much to the project directly, but provide a
> really solid base of knowledge to do further contributions.
> 
> So here's my challenge for you.
> 
> -------
> OUTCOME
> 
> Write a simple go program that will list the current cpu pools,
> similar to the output of "xl cpupool-list".  No need to handle extra
> arguments or modify libxl.go (beyond what may be needed to compile it).

RESULTS:
I've managed to get xen running on my local machine. I am running linux natively
on ubuntu with xen 4.8-unstable and it is running reasonable well.
There are two VM's running on my computer, one is named tutorial-pv-guest that I
created by following the xen beginners guide. The other is called ubuntu1 and
was created through a custom configuration file that I created. I wasn't having
much luck with the outreachy tutorial provided so after some googling the link 
below really helped me get through the process.

http://www.virtuatopia.com/index.php/Building_a_Xen_Guest_Domain_using_Xen-Tools

> 
> Please post a copy of your .go program, along with the results of
> output *when more than one VM is running*.

The output when I run "sudo go run libxl.go" is pasted below. The output was made 
when the two VM's mentioned above were running. It prints out the appropiate 
output for Pool Name, Scheduler, and Domain Count. 
All the changes in libxl.go are contained within the main() method and the libxl.go
file is pasted below as well.


CONCERNS/QUESTIONS:
I believe I was only able to print out the information for Name, Sched, and Domain 
count because the other information such as Active and CPU's are not stored within
CpupoolInfo. Was there a way I could obtain that information? I don't think the 
code privided had that functionality. Maybe the next task could be to add that 
functionality?
It also seems that Domain Count is off. The command "xl cpupool-list" lists 3 domains
(which are Dom0, tutorial-pv-guest, and ubuntu1) but my program returns 11 domains. 
Would you like me to look into the issue? I'm using the information called from 
Ctx.ListCpupool() so I may have to take a closer look at that code. 

Thank You!
Ronald Rojas

[-- Attachment #2: output --]
[-- Type: text/plain, Size: 45 bytes --]

Name		Sched		Domain count
Pool-0		credit		11

[-- Attachment #3: libxl.go --]
[-- Type: text/plain, Size: 6617 bytes --]

/*
 * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; version 2 of the
 * License only.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 * 02110-1301, USA.
 */
package main

/*
#cgo LDFLAGS: -lyajl -lxenlight
#include <libxl.h>
#include <stdlib.h>
*/
import "C"

import (
	"unsafe"
	"fmt"
	"time"
)

type Context struct {
	ctx *C.libxl_ctx
}

var Ctx Context

func (Ctx *Context) IsOpen() bool {
	return Ctx.ctx != nil
}

func (Ctx *Context) Open() (err error) {
	if Ctx.ctx != nil {
		return
	}
	
	ret := C.libxl_ctx_alloc(unsafe.Pointer(&Ctx.ctx), C.LIBXL_VERSION, 0, nil)

	if ret != 0 {
		err = fmt.Errorf("Allocating libxl context: %d", ret)
	}
	return
}

func (Ctx *Context) Close() (err error) {
	ret := C.libxl_ctx_free(unsafe.Pointer(Ctx.ctx))
	Ctx.ctx = nil

	if ret != 0 {
		err = fmt.Errorf("Freeing libxl context: %d", ret)
	}
	return
}

type Domid uint32

type MemKB uint64

// FIXME: Use the idl to generate types
type Dominfo struct {
	// FIXME: uuid
	Domid             Domid
	Running           bool
	Blocked           bool
	Paused            bool
	Shutdown          bool
	Dying             bool
	Never_stop        bool
	
	Shutdown_reason   int32 // FIXME shutdown_reason enumeration
	Outstanding_memkb MemKB
	Current_memkb     MemKB
	Shared_memkb      MemKB
	Paged_memkb       MemKB
	Max_memkb         MemKB
	Cpu_time          time.Duration
	Vcpu_max_id       uint32
	Vcpu_online       uint32
	Cpupool           uint32
	Domain_type       int32 //FIXME libxl_domain_type enumeration

}

func (Ctx *Context) DomainInfo(Id Domid) (di *Dominfo, err error) {
	if Ctx.ctx == nil {
		err = fmt.Errorf("Context not opened")
		return
	}

		
	var cdi C.libxl_dominfo

	ret := C.libxl_domain_info(Ctx.ctx, unsafe.Pointer(&cdi), C.uint32_t(Id))

	// FIXME: IsDomainNotPresentError
	if ret != 0 {
		err = fmt.Errorf("libxl_domain_info failed: %d", ret)
		return
	}

	// FIXME -- use introspection to make this more robust
	di = &Dominfo{}
	di.Domid = Domid(cdi.domid)
	di.Running = bool(cdi.running)
	di.Blocked = bool(cdi.blocked)
	di.Paused = bool(cdi.paused)
	di.Shutdown = bool(cdi.shutdown)
	di.Dying = bool(cdi.dying)
	di.Never_stop = bool(cdi.never_stop)
	di.Shutdown_reason = int32(cdi.shutdown_reason)
	di.Outstanding_memkb = MemKB(cdi.outstanding_memkb)
	di.Current_memkb = MemKB(cdi.current_memkb)
	di.Shared_memkb = MemKB(cdi.shared_memkb)
	di.Paged_memkb = MemKB(cdi.paged_memkb)
	di.Max_memkb = MemKB(cdi.max_memkb)
	di.Cpu_time = time.Duration(cdi.cpu_time)
	di.Vcpu_max_id = uint32(cdi.vcpu_max_id)
	di.Vcpu_online = uint32(cdi.vcpu_online)
	di.Cpupool = uint32(cdi.cpupool)
	di.Domain_type = int32(cdi.domain_type)
	return
}

func (Ctx *Context) DomainUnpause(Id Domid) (err error) {
	if Ctx.ctx == nil {
		err = fmt.Errorf("Context not opened")
		return
	}

	ret := C.libxl_domain_unpause(Ctx.ctx, C.uint32_t(Id))

	if ret != 0 {
		err = fmt.Errorf("libxl_domain_unpause failed: %d", ret)
	}
	return
}


// typedef struct {
//     uint32_t size;          /* number of bytes in map */
//     uint8_t *map;
// } libxl_bitmap;
// void libxl_bitmap_init(libxl_bitmap *map);
// void libxl_bitmap_dispose(libxl_bitmap *map);

// # Consistent with values defined in domctl.h
// # Except unknown which we have made up
// libxl_scheduler = Enumeration("scheduler", [
//     (0, "unknown"),
//     (4, "sedf"),
//     (5, "credit"),
//     (6, "credit2"),
//     (7, "arinc653"),
//     (8, "rtds"),
//     ])
type Scheduler int
var (
	SchedulerUnknown  Scheduler = 0
	SchedulerSedf     Scheduler = 4
	SchedulerCredit   Scheduler = 5
	SchedulerCredit2  Scheduler = 6
	SchedulerArinc653 Scheduler = 7
	SchedulerRTDS     Scheduler = 8
)

// const char *libxl_scheduler_to_string(libxl_scheduler p);
// int libxl_scheduler_from_string(const char *s, libxl_scheduler *e);
func (s Scheduler) String() (string) {
	cs := C.libxl_scheduler_to_string(C.libxl_scheduler(s))
	// No need to free const return value

	return C.GoString(cs)
}

func SchedulerFromString(name string) (s Scheduler, err error) {
	cname := C.CString(name)
	defer C.free(unsafe.Pointer(cname))

	var cs C.libxl_scheduler

	ret := C.libxl_scheduler_from_string(cname, &cs)
	if ret != 0 {
		err = fmt.Errorf("libxl_scheduler_from_string failed: %d", ret)
		return
	}

	s = Scheduler(cs)

	return
}

// libxl_cpupoolinfo = Struct("cpupoolinfo", [
//     ("poolid",      uint32),
//     ("pool_name",   string),
//     ("sched",       libxl_scheduler),
//     ("n_dom",       uint32),
//     ("cpumap",      libxl_bitmap)
//     ], dir=DIR_OUT)

type CpupoolInfo struct {
	PoolId uint32
	PoolName string
	Scheduler Scheduler
	DomainCount int
	// Punt on cpumap for now
}

// libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool_out);
// void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nb_pool);
func (Ctx *Context) ListCpupool() (list []CpupoolInfo) {
	var nbPool C.int

	c_cpupool_list := C.libxl_list_cpupool(Ctx.ctx, &nbPool)

	defer C.libxl_cpupoolinfo_list_free(c_cpupool_list, nbPool)

	if int(nbPool) == 0 {
		return
	}

	// Magic
	cpupoolListSlice := (*[1 << 30]C.libxl_cpupoolinfo)(unsafe.Pointer(c_cpupool_list))[:nbPool:nbPool]

	for i := range cpupoolListSlice {
		var info CpupoolInfo
		
		info.PoolId = uint32(cpupoolListSlice[i].poolid)
		info.PoolName = C.GoString(cpupoolListSlice[i].pool_name)
		info.Scheduler = Scheduler(cpupoolListSlice[i].sched)
		info.DomainCount = int(cpupoolListSlice[i].n_dom)

		list = append(list, info)
	}

	return
}

func (Ctx *Context) CpupoolFindByName(name string) (info CpupoolInfo, found bool) {
	plist := Ctx.ListCpupool()

	for i := range plist {
		if plist[i].PoolName == name {
			found = true
			info = plist[i]
			return
		}
	}
	return
}




func main() {
    err := Ctx.Open()
    if err != nil{
        fmt.Print(err)
        return
    }
    var list []CpupoolInfo = Ctx.ListCpupool()

    fmt.Print("Name\t\tSched\t\tDomain count\n")
    for _, info := range list {
        fmt.Printf("%s\t\t%s\t\t%b\n", info.PoolName, info.Scheduler, info.DomainCount)
    }



}

[-- Attachment #4: Type: text/plain, Size: 127 bytes --]

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

Re: New Outreachy Applicant

[George Dunlap]

On 03/10/16 06:14, Ronald Rojas wrote:
> On Tue, Sep 20, 2016 at 04:24:47PM +0100, George Dunlap wrote:
>> Thanks for your interest in the Xen Project!  Sorry for the delay in
>> responding -- somehow your mail either never made it to my personal
>> inbox or I accidentally deleted it instead of filing it properly.  I
>> saw your question on IRC and now found your mail here on xen-devel.
>>
>> First, I want to emphasize that Outreachy internships should be
>> considered a full-time job.  As part of the application process you
>> will be asked to confirm that you will not be taking any classes, nor
>> have any other significant commitments (such as another job) during
>> the period of the internship.
> 
> I'll confirm now that won't be taking any classes or working during the
> majority of the program, however the fall semester for my college will
> end around the 20th of December. 
>>
>> Now on to the bite-sized task.  We've actually found that one of the
>> difficult parts of getting going with our project is making sure that
>> you understand how to get your whole system and environment set up.
>> And another thing we want to see is to what degree you can balance
>> figuring things out, finding the answers on the web, and asking for
>> help when you need it.
>>
>> So with that in mind, we've started experimenting with tasks which
>> don't contribute very much to the project directly, but provide a
>> really solid base of knowledge to do further contributions.
>>
>> So here's my challenge for you.
>>
>> -------
>> OUTCOME
>>
>> Write a simple go program that will list the current cpu pools,
>> similar to the output of "xl cpupool-list".  No need to handle extra
>> arguments or modify libxl.go (beyond what may be needed to compile it).
> 
> RESULTS:
> I've managed to get xen running on my local machine. I am running linux natively
> on ubuntu with xen 4.8-unstable and it is running reasonable well.
> There are two VM's running on my computer, one is named tutorial-pv-guest that I
> created by following the xen beginners guide. The other is called ubuntu1 and
> was created through a custom configuration file that I created. I wasn't having
> much luck with the outreachy tutorial provided so after some googling the link 
> below really helped me get through the process.
> 
> http://www.virtuatopia.com/index.php/Building_a_Xen_Guest_Domain_using_Xen-Tools
> 
>>
>> Please post a copy of your .go program, along with the results of
>> output *when more than one VM is running*.
> 
> The output when I run "sudo go run libxl.go" is pasted below. The output was made 
> when the two VM's mentioned above were running. It prints out the appropiate 
> output for Pool Name, Scheduler, and Domain Count. 
> All the changes in libxl.go are contained within the main() method and the libxl.go
> file is pasted below as well.

Looks good, thank you!

> CONCERNS/QUESTIONS:
> I believe I was only able to print out the information for Name, Sched, and Domain 
> count because the other information such as Active and CPU's are not stored within
> CpupoolInfo. Was there a way I could obtain that information? I don't think the 
> code privided had that functionality. Maybe the next task could be to add that 
> functionality?

It looks like "cpus" is done by actually counting the bits in the cpu
bitmask, which was not (yet) implemented in the code that I sent you.  I
have since implemented bitmaps in my copy, but not yet a method to
automatically count how many bits are set.

I just looked at the xl implementation of 'cpupool-list', and discovered
that the line which prints the cpupool information looks like this:

                printf("%3d %9s       y       %4d", n,
                       libxl_scheduler_to_string(poolinfo[p].sched),
                       poolinfo[p].n_dom);

In other words, the "Active" field is totally bogus --  the format
string itself just prints 'y'!

> It also seems that Domain Count is off. The command "xl cpupool-list" lists 3 domains
> (which are Dom0, tutorial-pv-guest, and ubuntu1) but my program returns 11 domains. 
> Would you like me to look into the issue? I'm using the information called from 
> Ctx.ListCpupool() so I may have to take a closer look at that code. 

Actually I think you just have a typo in your program. :-)

Thanks for this -- if you're up for it, let me see what kinds of next
steps you can do (obviously when you have the opportunity).

 -George

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

Re: New Outreachy Applicant

[George Dunlap]

On Tue, Oct 4, 2016 at 3:23 PM, George Dunlap <george.dunlap@citrix.com> wrote:
> Thanks for this -- if you're up for it, let me see what kinds of next
> steps you can do (obviously when you have the opportunity).

So there are a couple of things we could do next.

* If you want a simple change that you can use to get experience with
sending patches to the list:

There are a number of instances in tools/libxl/xl_cmdimpl.c where
where domid is listed as uint32_t (or libxl_domid), but the printf
specifier is used as '%d'.  Change this to '%u'.

* If you want an investigation to do:

At least a couple of times I've accidentally run a golang program with
libxl functionality on a system that wasn't running Xen (i.e., I'd
rebooted onto Linux baremetal).  Instead of throwing an error, as you
would expect, it crashed with a SEGV.

Try to reproduce this bug, and see if you can fix it.

* If you want to dive into the project:

I can send you my most recent version of libxl.go (which has a few
more things implemented).  Modify it so that it builds as a package (I
think "xenproject.org/xenlight" is probably the best name), and wire
it into the build system in tools/golang/xenlight, and installs into
$prefix/share/gocode/src/xenproject.org/.

The key thing with the last one is not to get too bogged down in
systems you're not familiar with -- if you get stuck ask for help
relatively quickly; and if it's turning into a mess, I can just do the
Makefile side of things so that you can get to the actual Go side of
the project.

What do you think?

 -George

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

Re: New Outreachy Applicant

[Ronald Rojas]

On Wed, Oct 05, 2016 at 06:44:08PM +0100, George Dunlap wrote:
> On Tue, Oct 4, 2016 at 3:23 PM, George Dunlap <george.dunlap@citrix.com> wrote:
> > Thanks for this -- if you're up for it, let me see what kinds of next
> > steps you can do (obviously when you have the opportunity).
> 
> So there are a couple of things we could do next.
> 
> * If you want a simple change that you can use to get experience with
> sending patches to the list:
> 
> There are a number of instances in tools/libxl/xl_cmdimpl.c where
> where domid is listed as uint32_t (or libxl_domid), but the printf
> specifier is used as '%d'.  Change this to '%u'.
> 
> * If you want an investigation to do:
> 
> At least a couple of times I've accidentally run a golang program with
> libxl functionality on a system that wasn't running Xen (i.e., I'd
> rebooted onto Linux baremetal).  Instead of throwing an error, as you
> would expect, it crashed with a SEGV.
> 
> Try to reproduce this bug, and see if you can fix it.
> 
> * If you want to dive into the project:
> 
> I can send you my most recent version of libxl.go (which has a few
> more things implemented).  Modify it so that it builds as a package (I
> think "xenproject.org/xenlight" is probably the best name), and wire
> it into the build system in tools/golang/xenlight, and installs into
> $prefix/share/gocode/src/xenproject.org/.
> 
> The key thing with the last one is not to get too bogged down in
> systems you're not familiar with -- if you get stuck ask for help
> relatively quickly; and if it's turning into a mess, I can just do the
> Makefile side of things so that you can get to the actual Go side of
> the project.
> 
> What do you think?

I think I would prefer to do the first task and then the last task. I 
have not used stgit so I think it would be beneficial to do that first
and then I can dive into the project. 
I will probably do the first task on either Sunday or Monday, depending
on when I can start working on it. The packaging task seems much more 
difficult and I really only have a significant amount of time to work 
on this during the weekend, so it'll probably take 1 or 2 more weeks 
to complete that. 
In the meantime I think it would be helpful to look at the makefile 
of another subproject from xen so I could get some inspiration on how 
structure this new project. Is there any Makefile that you think I 
should look at? If not I'll just read through a couple of files in xen
and try to follow a similar style. 

Does that sound like a good plan?
 
Ronald Rojas

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

Re: New Outreachy Applicant

[George Dunlap]

On 06/10/16 15:26, Ronald Rojas wrote:
> On Wed, Oct 05, 2016 at 06:44:08PM +0100, George Dunlap wrote:
>> On Tue, Oct 4, 2016 at 3:23 PM, George Dunlap <george.dunlap@citrix.com> wrote:
>>> Thanks for this -- if you're up for it, let me see what kinds of next
>>> steps you can do (obviously when you have the opportunity).
>>
>> So there are a couple of things we could do next.
>>
>> * If you want a simple change that you can use to get experience with
>> sending patches to the list:
>>
>> There are a number of instances in tools/libxl/xl_cmdimpl.c where
>> where domid is listed as uint32_t (or libxl_domid), but the printf
>> specifier is used as '%d'.  Change this to '%u'.
>>
>> * If you want an investigation to do:
>>
>> At least a couple of times I've accidentally run a golang program with
>> libxl functionality on a system that wasn't running Xen (i.e., I'd
>> rebooted onto Linux baremetal).  Instead of throwing an error, as you
>> would expect, it crashed with a SEGV.
>>
>> Try to reproduce this bug, and see if you can fix it.
>>
>> * If you want to dive into the project:
>>
>> I can send you my most recent version of libxl.go (which has a few
>> more things implemented).  Modify it so that it builds as a package (I
>> think "xenproject.org/xenlight" is probably the best name), and wire
>> it into the build system in tools/golang/xenlight, and installs into
>> $prefix/share/gocode/src/xenproject.org/.
>>
>> The key thing with the last one is not to get too bogged down in
>> systems you're not familiar with -- if you get stuck ask for help
>> relatively quickly; and if it's turning into a mess, I can just do the
>> Makefile side of things so that you can get to the actual Go side of
>> the project.
>>
>> What do you think?
> 
> I think I would prefer to do the first task and then the last task. I 
> have not used stgit so I think it would be beneficial to do that first
> and then I can dive into the project. 
> I will probably do the first task on either Sunday or Monday, depending
> on when I can start working on it. The packaging task seems much more 
> difficult and I really only have a significant amount of time to work 
> on this during the weekend, so it'll probably take 1 or 2 more weeks 
> to complete that. 
> In the meantime I think it would be helpful to look at the makefile 
> of another subproject from xen so I could get some inspiration on how 
> structure this new project. Is there any Makefile that you think I 
> should look at? If not I'll just read through a couple of files in xen
> and try to follow a similar style. 
> 
> Does that sound like a good plan?

Yes, that sounds good.

I should make it clear --  nobody *expects* work from you until such
time you're being paid. :-)  Doing small tasks (like the %d -> %u
change) helps us get a better idea what your capabilities are, and so
can be helpful for the decision-making process.  But it won't be counted
against you if you don't do any more small tasks; and it *definitely*
won't be counted against you if you don't do the large things.

I've talked about next steps for the larger project because you
expressed an interest in them.  They're there to do if you *want* to,
and if you have time, but it's on a strictly voluntary basis, and you
should absolutely prioritize your schoolwork.

Pressuring people into working for free with the vague promise of
something in the future is usually dishonest, and you should be wary of
anyone trying it on you.

Hope that makes sense. :-)

Let me take a look at a simple example you could use to "wire-in"
something to the build system.

 -George

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

Re: New Outreachy Applicant

[George Dunlap]

On Thu, Oct 6, 2016 at 4:16 PM, George Dunlap <george.dunlap@citrix.com> wrote:
> Let me take a look at a simple example you could use to "wire-in"
> something to the build system.

Probably the simplest example of how to "wire in" a directory is tools/xentrace.

For the moment, I would just hardcode it in tools/Makefile (as
xentrace is); we can work on getting an option to `configure` later.

It should be pretty straightforward to take tools/xentrace/Makefile
and modify it to do what you need.

The primary difference is that due to the way Go operates, the main
thing you want to install is the go files themselves, rather than a
compiled binary.

Anyway -- why don't you find me on #xendevel when you get a chance and
we can walk through what the Makefile should do. :-)

 -George

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