Project UDI

For those of you who are linking to this page from outside the main OZONE site, it can be seen here. OZONE is an OS I wrote myself that combines my favourite parts of VMS, Linux and WindoesNT. I am in the process of porting UDI to OZONE and vice versa.

Project UDI is a standard for writing device drivers. The goal is to have drivers that will run on any hardware and software platform that is compatible with the physical hardware. So if you have some PCI board from someone and they supply an UDI driver for it, you can just plug-and-pray!

UDI can be used as a drop in I/O system if you don't already have one. I had one, so I basically fit UDI in as another driver. The way I look at it is, that UDI is a very sophisticated piece of 'hardware' that you access via subroutine calls instead of programming I/O ports.

So, for example, I have an OZONE SCSI device driver that calls UDI to do SCSI I/O's. These things are called 'mappers' in UDI parlance. I have written the SCSI mapper (by hacking up the Linux one), but I haven't tested it at all yet. So now any SCSI controller that comes along with an UDI driver will 'instantly' work.

If you are looking for info on how to write driver's for UDI, this page is not really geared for that. This is more along the lines of all the 'behind-the-scenes' stuff that is necessary to set up the UDI environment on an operating system. I don't really have much knowledge about how to write an UDI driver!

With that in mind, I try to keep the the stuff on this page is along the lines of this analogy:

Here's what I did / am doing to port it:

  1. I got a copy of the reference library from
  2. Copied the env/linux directory to env/ozone
  3. Went through the modules in env/ozone one-by-one and converted the routines to call the equivalent OZONE routines. This was actually fairly painless, as OZONE had almost all the things that UDI wants. (I even at points felt pitty for poor Linux kernel programmers). The only thing I had to add to the kernel was a routine to return how much room was left on the caller's kernel stack. I didn't have to mess with the code in the 'common' directories.
  4. Compiled the stuff and linked together an image called udi_env_init.oz. File udi_env_init.c is basically the 'main program' of UDI. So you may be able to start your porting effort here and port the modules that this one references, and so on until you can link with no undefined symbols. The result can be dynamically loaded or statically linked into your kernel. But at any rate, once loaded, get its start routine called so it can do its initialization stuff.
  5. Compiled and linked the 'metalanguage' driver/library thing for bridge devices. This is the code that changes the public-callable udi_... routines into the per-driver xxx_... routines related to bridge devices.
    A 'metalanguage' is the formal definition of the communications between regions, called channel operations.
  6. Next thing to do is get the PCI bridge driver going. This is basically a set of routines that things like SCSI and ethernet drivers call to access the PCI bus, as UDI drivers are not allowed to have direct I/O calls. I had to put in OZONE-specific calls for scanning the PCI bus and for doing I/O instructions, and also hook up the interrupt routine.
  7. Next I got an 21140-based ethernet card that is somewhat supported by UDI, and compiled and loaded the network metalanguage library and the ethernet driver. I also compiled and loaded the gio metalanguage library needed by the network driver. I had to hack on the shrkudi.c driver somewhat, as it did not drive my board correctly. But this is a problem with Tulip based drivers in general, as different boards wire the chips up differently.

As of today (Feb 14, 2), the whipit test program works! It sends out packets continuously on the network. I don't have an 'unload' or anything like that so I have to reboot to stop it, though. So now I can turn the TV on.

Now I will try to get it to work with my IP stack. This is where I tune a channel in on the TV and watch.

Here are summaries of questions I have asked the Project UDI developers (so far). The answers in italics represent my understanding of the answer I got, and are in no stretch a direct quote of any one on the Project UDI development team, and are usually composites of answers.

Things I've had to do to my kernel to handle UDI:

Things that I didn't port correctly to begin with: