TODO list
The document states some of the TODOs with regard to future releases of JNode. There is no particular date when the targets should be finished, but it should give you some hints, what you could look at :
- XYZ Filesystem: There are many other filesystems that could be added to JNode. Or existing readonly filesystems could be extended for write support. A list of possibilities includes: NFS, Samba, ssh fs, ftp write support, ntfs write support, ...
- Partitiontool: We need harddisk partitioning support. That includes a commandline version like fdisk but could also be extended for a graphical version. The GUI version can be written using charva or swing or both
- Grubinstaller: Some code to be able to install grub to the harddisk. That means, install stage1 into MBR, stage1.5 as needed and for both files the hidden data structures have to be updated. A "highlevel editor" for the menu.lst file would be fine, too.
- HTMLDemo: Classpath contains a little "webbrowser", it would be nice as a showcase for JNode. It's contained in examples.zip, but it has to be extended, because at the moment it's only usable for testing classpaths HTML renderer
- Device Drivers: Device Drivers are a very important part of an operating system. If you have a peace of hardware that isn't included in JNode yet, and you have some hardware/lowlevel skills you're welcome to add support for it. This includes either adding support for a new hardware for an existing API (e.g. network cards, graphic cards, HIDs,...) but also adding hardware that was not present in JNode before (e.g. Framegrabber (bttv,..), CD Writer,...).
- SWTswing: Port of SWTswing to JNode. This is needed to be able to run eclipse inside JNode. BTW, if that works, porting eclipse is the next TODO on the list
- JSR80: Interfacing the current JNode usb api to the javax.usb api as descriped in JSR80 API Specification.
- JNodeTools: Implement a tool to create and edit the plugin descriptors. Either as a eclipse tool or standalone app (so it can be used in JNode too). See also here
- JNode Commands: We need to expand and improve the suite of JNode utility commands that can be run from the command line. Rather than reinventing the wheel, JNode commands should aim to be compatible with commands defined in the relevant POSIX specification; i.e. IEEE Std 1003.1, 2004 Edition
Student Projects
In order to imply students in JNode, I will expose here some projects.
Git repository
The gitorious project is located here : http://gitorious.org/jnode.
It's compound of:
- svn-mirror, which is a mirror of the subversion repository
- a set a clones of svn-mirror, one for each student project
Contact
If you are interested, you can contact me (Fabien DUMINY) :
- with my jnode.org contact form (in english or french)
- with my blog contact form :
Remarks
- Since it's a draft, that document may evolve
- In order to have some warranty of real work, I have contacted some schools to imply students in these tasks. These students will be served first and in the order of their arrival
Classical projects
Here is a list of classical projects.
Legend :
(A) : project assigned
Level :
(*) : easy
(**) : average
(***) : difficult
(****) : very hard
: unknow
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)
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
Implement realtime specification for Java
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
- write a DeviceToDriverMapper that will detect virtio devices in jnode. Look at the function virtio_pci_probe in the linux kernel.
- write a driver for the virtio devices
- block : Look at virtio_blk.h and virtio_blk.c in the linux kernel
- network : Look at virtio_net.h and virtio_net.c in the linux kernel
- Level : easy/average
- Assigned to : Ibrahim Ghiyati and Yi Xenfung
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
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 :
Generic projects
Here is a list of generic projects
Legend :
(A) : project assigned
Level :
(*) : easy
(**) : average
(***) : difficult
(****) : very hard
: unknow
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 :
Experimental projects
Here is a list of experimental projects
Legend :
(A) : project assigned
Level :
(*) : easy
(**) : average
(***) : difficult
(****) : very hard
: unknow
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 :
- Assigned to :