Complete AMD 64 support

• Description : The 64bit port has some bugs but it's not exactly known where and how many. This task is especially difficult as the bugs have to be spotted first. Is this enough work for a student project ?
• Level : Timeconsuming (Depends on finding the bugs)
• Assigned to :

Complete multi CPU support

• Description: Multi-CPU support is broken. There are bugs in JNode's Apic implementation and the scheduler is suboptimal in regard to SMP. This project involves fixing the (L)Apic handling and if time permits replacing the scheduler with an SMP efficient one.
• Level : average/hard (many informations are needed to complete the task)
• Assigned to :

Complete the vesa driver

• Description : The current vesa driver need grub support to detect and set the video mode at boot time. The driver should be extended to become independant of grub (and be able to switch to any supported graphic mode).
• Level : hard (many informations are needed to complete the task)
• References : implements the vbe3 specifications and other references gathered on jnode site
• Assigned to :

Implement full ddx support without 2d and 3d

• Description : With ddx, which stands for full modesetting, you can detect the monitor, you can set any resolution, (sometimes you can rotate the screen) and you have multihead support. From the performance point of view, it will faster than a vesa driver but slower than a chipset specific driver
• Level : moderate/hard
• Assigned to :

Implement javax.comm API (A)

• Description : The javax.comm API allows to access serial and parallel ports in java. I have been told that the javax.comm package can't be used to avoid legal issues : the rxtx project has choosen the gnu.io package instead.
• References : specifications of the API, its javadoc
• Tips : use the RXTX library
• Level : easy
• Assigned to : Mihail Argranat (blog)

    The git repository is located here

Implement new GC algorithms for better performances (A)

• Advice : contact Peter since he has ideas about the subject and could give good practices to avoid breaking jnode for such a task
• You should have read this and understood at least the Basic Algorithm. In the terms of that page, JNode's gc is a conservative, non-moving, non-generational, stop-the-world mark&sweep algorithm. Improvements can be many-fold, basicaly removing one of the "non"s Good information with much stuff about memory management and garbage collection can also be found on this site. You can find another explanation of the naive mark&sweep, with a graph on this site
• Level : This can be anything from easy to extremly hard. Depends on actual task.
• Assigned to : Loïc Rouchon, Benoit Sautel and Ismael Merzaq

    The git repository is located here

Implement realtime specification for Java

• Description : It's also know as RTSJ and JSR-282
• Level : extremely hard
• Assigned to :

Implement virtio drivers for jnode (A) (*/**)

• Description : Virtio allows to have drivers (network, hard drive ...) faster than regular ones running in virtualized environments (kvm, VirtualBox, vmware, xen ...).
• References :
  • Rusty Russell (a linux kernel developer) is writting specifications of virtio. He will really appreciate your feedback (his mail is in the document).
  • You can also have a look in the sources of the virtio drivers for the linux kernel. You should also have a look at the includes directory (search for virtio*.h files).
  • http://www.linux-kvm.org/page/Virtio
  • http://lwn.net/Articles/239238/
  • http://portal.acm.org/citation.cfm?id=1400108&dl=GUIDE&coll=GUIDE&CFID=5...
  • small doc explaining the basic idea : http://ozlabs.org/~rusty/index.cgi/tech/2007-05-21.html
  • also look at existing implementations (in kvm)
• Steps
  1. write a DeviceToDriverMapper that will detect virtio devices in jnode. Look at the function virtio_pci_probe in the linux kernel.
  2. write a driver for the virtio devices
     1. block : Look at virtio_blk.h and virtio_blk.c in the linux kernel
     2. network : Look at virtio_net.h and virtio_net.c in the linux kernel
• Level : easy/average
• Assigned to : Ibrahim Ghiyati and Yi Xenfung

    The git repository is located here

Implement write support for the iso 9660 file system

• Description : iso 9660 is a norm that defines how data are stored in compact discs (cdrom, dvdrom ...). For now, we have only a limited read support for cdroms.
• Level : Hard ?
• Assigned to :

Integrate JDistro

• Description : It would be great to have that advanced desktop in JNode. I am not sure if there is really a licensing issue or not (JDistro is GPL and JNode is LGPL)
• Level : Hard
• Assigned to :

Port jnode to another CPU

• Description : For now, we only support x86 CPUs but it would be great to have support for other CPUs. Examples : ARM (used in small devices like mobiles), PowerPC, ...
• Level : hard
• Assigned to :

Port jnode to grub 2

• Description : Currently, JNode uses the grub bootloader. Using grub 2 would allow to openup to more plateforms like, for example, non BIOS-based architectures (aka EFI ones).
• Level : average/hard (many informations are needed to complete the task)
• Assigned to :

Write a driver for a sound card

• Tips : implement a driver for intelhda since all sound chips nowadays comply with it.
• Level :
• Assigned to :

Write a driver for Serial ATA (sata)

• Reference : Wikipedia page about Serial ATA (sata)
• Tips : implement compliance with ahci.
• Level :
• Assigned to :

Write a file system checker (**/***)

• Description : Writing a file system checker would not only help ensure that a file system is clean at boot time (like linux distro are doing). It will also allow to help fixing bugs in the current implementations of the file systems. For each of these file systems, a checker could be a student project by itself : ext2, fat32, fat12/16, ntfs (I am not sure about that one since it's hard to get ntfs specifications). The first student to work on a file system checker will have to define an API because we don't have yet one.
• Level : Average (depends on the file system complexity)
• Assigned to :

write a virtual keyboard

• Description : look at that topic for more informations
• Tips : JDistro has virtual keyboard which should be made standalone for reuse in JNode but I am not sure if there is really a licensing issue or not (JDistro is GPL and JNode is LGPL) ...
• Level : easy
• Assigned to :

write an open GL driver

• References : open GL organisation
• Level : extremely hard
• Assigned to :

Write another desktop for JNode

• Description : To be specified with the student.
• Level :
• Assigned to :

Write SWT peers

• Description : SWT is the widget toolkit used by eclipse. It has a java API and rely on native peers for the actual display of widgets. To be able to use SWT, one should implement SWT peers for JNode.
• Level : average/hard
• Assigned to :

Implement an API

• Description : which APIs ?
• Level :
• Assigned to :

Write a command

• Description : It could be a big command or a set of smaller commands. It should be Linux commands.
• Level :
• Assigned to :

Write a plugin for eclipse ?

• Description : for doing what ?
• Level :
• Assigned to :

Write drivers for old legacy devices

• Description : which devices ?
• Level :
• Assigned to :

Study and experiment usage of gradle as a replacement of our build system

• Description : For now, we are using ant + a set of custom ant tasks. I think gradle, in addition to keep things from ant, maven and ivy, add interesting possibilities :
  • groovy scripting ability : more flexibility than xml based build systems. For example, you can do something before and/or after a given (set of) task(s) : it could be used to transform ant's jar task into a jnode's plugin packager (a jnode plugin is a regular jar file which contain a plugin descriptor file)
  • interaction with ivy : look at gradle's faq for ivy
  • interaction with maven 2 : look at gradle for maven 2 users and gradle's faq for maven
  • interaction with ant : look at gradle's faq for ant
  • you can find main features here
• Level :
• Assigned to :

Study and experiment usage of OSGi to manage plugins

• Study and experiment usage of OSGi as a replacement of current jnode's specific plugin framework (inspired by eclipse's one)
• Advice : The developer will have to deal with with Classloaders. It sounds to be a very hard task; It might even happen that's not a suitable replacement for our current plugin framework;
  Moreover, the incoming modules for openjdk7 (project jigsaw) might come in the way/interfere with osgi. So, in my opinion, it's an heavily experimental task !
• Tips : Look at one of these implementations of OSGi :
  • Apache Felix
  • Eclipse equinox
  • knopflerfish
• Assigned to :