On the occasion of the new release of our main products, GVirtuS and JaClouX we are pleased to announce the first “UniParthenope OpenSource Lab Party”.
The party will be held on March 16 2011 in the Faculty of Science and Technology of the University of Napoli “Parthenope”.
The party will be organized as a conference where there will be held talks about the projects developed in the OpenSource Lab.
In particular will be presented:
- GVirtuS, a framework for the implementation of split-driver model and the of virtulization of hardware devices.
- JaClouX, an open source, cloud independent, Java API for high performance cloud computing application design, development, simulation and evaluation.
During the party it will be possible to meet and talk with the developers of the laboratory.
Further news about the party will be posted on the OSL website: http://osl.uniparthenope.it/tag/osl-party.
The Uniparthenope OpenSource Lab Team.
cloud, cloudcomputing, cuda, gpu, gvirtus, osl-party
Starting from the changeset 266 gVirtuS doesn’t have anymore an XML configuration file, the new format is the simple .properties one.
A .properties file is just a collection of key-value separated by a colon, like in:
Comments are supported, a comment starts with the “#” character and ends at the end of the line.
I was feeling that XML format was to complex for the simple configuration stuff needed by gVirtuS, and in this way it isn’t needed anymore to link gVirtuS binaries against the expat XML parser library.
At the moment it is needed just a configuration entry for running gVirtuS: the communicator. The communicator configuration entry is more a structure than a simple value (i.e. it is needed to specify the type of the communicator and the parameters for the type), to pack all the needed informations in a single string it is used an URL like syntax, so the value of the communicator entry is something like:
type://paremeter_1:parameter_2:...:paremeter _n
A “real life” sample that uses an AfUnix communicator bounded on /tmp/gvirtus with read and write permissions for everyone is:
communicator: afunix:///tmp/gvirtus:0666
The communicators supported ad the moment, with respective configuration entry, are:
- afunix, afunix://path:mode
- shm, shm://
- tcp, tcp://hostname:port
- vmshm, vmshm://hostname:port
Starting from the same changeset is shipped a default configuration file that it is automatically installed in the default location.
Please tell me what do you think about this change!
configuration, gvirtus, osl
VMShm is a mechanism that enables qemu virtual machines to access to POSIX shared memory objects created on the host OS.
VMShm make it possible to an user space application running in a virtual machine to map up to 1M of a POSIX shared memory object from the host OS.
It can be used as a base to build up an high performance communication channel between host and guest(s) OSes.
Read the rest of this entry
gvirtus, hpc, kvm, osl, qemu, shm
From this release (01-beta2) we support cudatoolkit >= 3.1. The legacy compatibility for cudatoolkit versions older than 3.1 is not guaranteed.
In this release there are also some minor changes and bugfixes.
The frontend now is named “libcudart.so.3″, so it is not needed anymore to rename it or to preload it.
The AfUnix communicator now has a new (optional) option, “mode” for setting the permission on the socket file (0660 for default).
Go to the Project Page and to the Download Page.
cuda, gvirtus, osl
On the release note of Fedora 14 there is the introduction of the support for developing using the D programming language, so I’ve readed something on that language and I feel that probably I can actually use it, the main interesting feature for me is the simple interoperability with code written in C.
So just for testing purpose I decided to write a small CUDA (I’m pretty sure that you already know what is cuda) application using the D language.
Of course is not possible to write CUDA kernel and device functions directly in a D module so what is needed is to implement kernels in a cuda source file (with a proper launcher) and then use the kernel from the D module.
The application that i’ve written converts a string in uppercase, reading the input from the command line (remember is just for testing).
Read the rest of this entry
cuda, D, D-language, Fedora, osl