Sandbox

CHII (Continous Hardware Intelligence Integration)

  • Launchpad Entry:CHII

  • Created: dhillonv10

  • Contributors: dhillonv10 for now Smile :)

  • Packages affected: linux-kernel

UPDATE: I am packaging Dtrace, into a debian package so it can be easily used over at Ubuntu, and the license conflicts have been resolved.

Summary

This proposal deals with making device drivers automatically customised for that machine, using linear regression and or SVM approach. These topics are a used as a part of Computer Vision for a long time now and thus can be successfully applied to a different situation. Basically, we have device A and a driver A1 that goes with it, now the hardware company releases a new device B which has some enhancements to device A but it almost the same thing. Now the developers have to make a new driver B1 that would go with this new device and if a lot of people upgrade to this new device the driver A would be useless to them. I want to make a classifier that based on the hardware interaction level modified driver A over time so that now its compatible with device B.

Release Note

This idea when completed would have a great impact on driver coding, the developers won't have to code a lot of new drivers for new devices that come out, and since I want to use Java for the construction of the classifier, thus it will be architecture independent so the whole Linux community can benefit from it.

Rationale

Right now we are fortunate to have a lot of developers writing device drivers for Ubuntu. Writing device drivers is an arduous task, and when new devices come out and people upgrade to them, the previous work of developers goes in vain. They have to write new drivers for that new device. CHII has the potential of automatically making the drivers and solving on of the problems why people don't switch to linux: unsupported hardware. Not only that, if this project is successful we can plug in almost anything into the computer, through the USB, run the classifier and have the driver made in a matter of time.

User stories

  • Brett got a new laptop this year, and heard about Ubuntu from a friend. He tried out Ubuntu from the live-cd and doesn't get Wi-fi on his laptop, he Ubuntu but needs Internet for his work. CHII can make a new driver for his computer and thus prove to be the convenience tip for him to switch over to Linux
  • John wants to listen to music on his Linux desktop but can't because his sound-card isn't supported yet. CHII can make a new sound driver for him so he can enjoy music

Assumptions

  • We are able to get a high success rate from the classifier
  • Classifier is not taking too long to create and optimize a driver
  • Omega is working in real-time and identifying any possible bugs

Design

Basic Idea

So here is what I want to accomplish: Have lots and lots of drivers from different architectures bundled into one huge database, then make a Java class that can write a generic driver from the ones already present in a category of drivers by using linear regression so a driver can be customised to provide the best performance for that machine. The classifier will be trained with metadata analysis and then applied to unknown conditions. The training will go on for a long time with the task of choosing the best parts from different drivers and writing a new one, so we won't have any driver problems and the whole Linux drivers incompatibility will be gone. I got this idea from Gentoo which basically compiles the entire kernel and other system components on your computer, this makes the software customised for that hardware alone and perform better. I am trying to get something similar accomplished with device drivers.

This indeed is a very hard task because computer doesn't understand what the code is and what it can do. But there are ways to make a computer understand the data. I understand that I am not a solid contributor to Ubuntu and my contributions have been rather insignificant but this time I know what I am talking about. I have been exposed to this for a long time.

A similar approach has been followed in NDISwrapper, this software understands the Linux API and the Windows API so the network cards can be like architecture independent. The Unified Kernel Project is trying to accomplish something similar: porting all the important firmwares, so that they can be architecture independent.

Metadata Analysis

This is the second pillar of CHII, the drivers would have to be thoroughly analysed and for every line we will need make a careful metadata analysis, which basically means that we make some data that corresponds to some other data in our case this is the driver information. This analysis could take a long time (a few hours) but the result would be like tagging the wikis. We would have a new language that our software understands and when the software is run on a new computer, the metadata analysis would make inferences based on previous trainings and make the new driver software. Once this is accomplished I will put up the metadata analysis on launchpad, so people can have a look at it and change it if necessary.

Implementation

CHII will be divided into a lot of sub-sections or folders each containing certain piece of code to make the overall project work and easy to navigate

Programming Details

Dtrace, Real-time Java and Java Native Interface (JNI) will be used to make system calls and access information in kernel-mode

Snapshots

We will have a Java class that takes the snapshot of all the drivers present on a machine, this will involve identifying all the drivers that work currently on that machine, their UID's and some other basic system and driver information such as the kernel version, type of driver i.e. USB. Then the python script will go to the database of drivers that we supply and get all the drivers and any firmwares required, then divide them into sub-categories based on our defined rules, for example: Audio, Graphics, etcetera. This will serve as our baseline, a copy of the baseline will be made and stored somewhere safely, so if something goes wrong we can undo all the changes made. -- Dtrace

User space drivers

Not all drivers have to be integrated into the kernel, they can also be user space drivers. If the driver needs to respond to interrupts, then we really need to be working in kernel space, and need to write a real device driver, as there is no good way at this time to deliver interrupts to user processes.

Classifier design

Just about all the tasks mentioned here can be accomplished in Dtrace. The classifier is the backbone of CHII as it is the only learning based component here. Here's an overview of the classifier:

  • Determine the category of the driver, this could be user supplied or automatic
  • Go to all the drivers already present for that category in the snapshot and select one that matches the architecture
  • Now here's the crucial part: the driver chosen in the last part, is tracked every system call, kernel mode request, hardware resources request, and memory allocation will be stored in a file. Netbeans already has the memory allocation mapping feature.
  • Use this mapping and apply it to the new device, obviously a lot of it won't work, but some will because in the core both the devices get similar things accomplished.
  • Use recursive backtracking to change the values in the stored file for the ones that don't work for the new device, this will take the longest because it based on trail-and-error. This part will require access to the meta-data analysis so that it can easily access part of a file as defined by the meta-data.
  • Store the changed values in a new file so that it can be accessed at a later time, this is the learning part because the file list will grow and the classifier will access it to make new drivers over time.
  • Once the interaction is fully achieved, make a copy of the driver for Omega, then install the new driver as a module in the kernel and then start Omega

Omega

This would be like the real-time bug tracker, performance checker and the optimizer. Here's how Omega will work:

  • Run as a start-up process
  • Remember the driver that was created, make a folder with that driver's name and then use the same methods created in the classifier to track the memory, system calls and such. Omega will match these calls to the driver that of the copy of the driver that was created.
  • As the checking goes on, the system calls will match to the ones that are being done at one point in time. This will be our check so the newly created driver works fine, if it doesn't Omega will unload the module and inform the user to run the classifier again.
  • Omega will be written using real-time Java to prevent slowing down of the system while the checking is going on

FAQ

  • Drivers written in an interpreted language are slower than the ones written in a compiled language, Java shouldn't be used

CHII isn't creating any new drivers, we are just modifying the ones that exist so that they can fit a new device

  • How far are you in this project?

Since I have to go to school so I try to spend as much of my free time possible to this and so far I have been reading a lot to get an idea of where I am going

  • Great! But why are you presenting this idea to us

I want a lot of people with different perspectives to have a look into this idea and tell me what they think. Also to get some people to help me out here

  • Where is the project home

Project Home, I try to keep this site updated

  • What will be the estimated time?

Currently I think it shouldn't take longer than an year, but I am not sure about the time frame Smile :)

  • Dtrace is a Solaris tool, how will that work in Ubuntu?

There is progress being made to assist the porting of Dtrace and there are some working versions available

  • How will this project benefit Linux community?

This drivers will be hardware independent thus helping every distro, especially Solaris and Open Solaris because both of these distros have dtrace embedded in the kernel

Any Comments

What do you guys think???


CategorySpec

dhillonv10/Sandbox (last edited 2010-01-01 20:08:46 by 66)