LxDM
Mission Statement

The LxDM has the following mission statement.

The Linux Driver Model project aims to standardize kernel-level interfaces for loadable modules so that drivers not part of the monolithic tree can be designed on a guaranteed ABI and, ultimately, can become loadable by all future kernel releases.

Purpose

The purpose of the Linux Driver Model, or LxDM, is to bring third party vendor support to Linux for hardware drivers. This will help to solve the problem of unsupported hardware.

On the most popular operating systems, hardware vendors supply hardware drivers with their hardware. Microsoft Windows, for example, has a driver model which allows Windows ME, 2000, and XP to share the same binary drivers. This allows users to buy a piece of hardware and be sure that they can upgrade their OS without losing support for their hardware.

On Linux, there are some cases where drivers can be loaded on multiple kernel versions, usually involving "Module Versioning Support." Usually, however, it is very difficult if not impossible to create drivers that work cross-version. Drivers for 2.4 won't work on 2.6; drivers for 2.6.2 may not even work properly on 2.6.8.1. Most vendors don't even bother attempting to write drivers for Linux; those that do normally have a compiled object with some open source "glue" that gets compiled against the current kernel sources.

For third party support to become a reality, Linux needs to supply a way for vendors to supply closed-source drivers that are guaranteed to load on all future versions of Linux, including the current and probably the most recent previous version. The LxDM project aims to bring this feature to Linux.

The LxDM project isn't about showing the power of open source, or bending vendors to the will of the community; it is about assisting Linux in its advancement to a suitable desktop operating system. When the system is easy to use and has real third party vendor support, it can easily begin replacing other operating systems. We need to work with third party vendors, not against them, in order to achieve this goal. Nobody forced Linus to make Linux GPL; we should extend the same courteousy to vendors who wish to support Linux without releasing their intellectual property.

How LxDM will be valuable

LxDM is a very valuable project. By supplying third party vendors with a guaranteed interface to write their drivers for, we are guaranteeing that they can choose to support Linux without releasing extra information. In doing this, we are raising the value of Linux by making it possible for hardware which we do not have vendor documentation on to be supported under Linux.

LxDM will help realize the goal of bringing Linux into the home of non-technical users. Linux drivers for hardware will be available with the hardware, in a form not specific to the kernel version. LxDM drivers may require a Linux kernel with an LxDM of at least a certain version; but, aside from interfaces removed for security reasons, LxDM interfaces will all be compatible with all prior releases. A driver for LxDM v1.0 will work on LxDM v3.5, and so on.

When a user has to wait for a driver to be written for hardware, that user is faced with a bad user experience. He cannot enjoy the operating system if the interface is crisp, the software is fast and stable, and his webcam just won't work until a driver is finished in a year and a half.

It is the personal goal of the LxDM founder to see Linux properly function as an actual usable OS. In its current form, it is very useful to hackers, who know how to hardware shop or maybe even write their own drivers; however, the average lay person does not want to and in some cases does not have the technical knowledge to shop around for hardware that he can actually use. This is a "rough edge" that needs to be smoothed out.

Linux only has rough edges left; there is no missing functionality. If these bits of lackluster are polished off, then we truly will have an OS that can take the market if the market wants it. I feel that this is only a little contribution on my part, but I do feel that by taking my best effort to motivate the community into tackling these problems, I am doing my part in bringing all of our work, our hopes, and our dreams to fruiton. The Linux zealots need to open their eyes and realize that the system is not perfect; the rest of us need to do what we can to make it perfect.

Compatibility

Each release of the LxDM will be backwards compatible with the last. Drivers for LxDMv1 will work for LxDMv2, LxDMv3, etc. Any structural changes will be incremental with multiple structures, i.e. rather than adding on to or subtracting from struct struct_foo in v2, there will be a struct struct_foo_v2.

Features

Being as I have no clue what I'm doing, I can't comment on what features I'd like the LxDM to supply. The developers will have to figure this out; however, I'm currently thinking that some easy way to bind things together and simplify operations would be a good step.

LxDM will supply an Applications Binary Interface that is always backwards compatible with previous LxDM versions if at all possible. The difference between an ABI and an API is that an ABI consists of the actual exported symbols--functions and global variables--and the structures that the kernel supplies; while an API consists of the macros, typedefs, and static inlines that are used to access these symbols and structures.

Before release, LxDM will always be examined heavily for potential landmines. Any potential security hazards in the ABI will be removed. Of course, loading an untrusted module is a security hazard itself; and there's not really much that can be done to make allowing some foreign code to execute in kernel space (= driver) any less secure.

I realize that different code is going to exist for USB, PCI, ISA, serial, IDE, and SCSI devices on the same chipsets; if at all possible, it should be easy to find these chipsets on these interfaces, bind the driver to them, and operate with the same LxDM functions. I don't like to see projects like Prism54 which spend significant time with the code ready to support USB devices but without the "USB glue" written yet, and I'm sure it costs vendors extra money when they have to have their hired programmers write such "glue."

This should be treated like any other open source project: the best of the best comes out of this, not just some hackish crap to support closed drivers. LxDM will be aiming for mainstream inclusion. The developers should make it their goal to produce a quality ABI that works as well as possible for the job; and to create an API that may even attract open source developers to move their drivers over to LxDM. Remember: if Linus Torvalds would write a driver using it, a third party vendor would write a driver using it.

LxDM won't be entirely about creating new symbols (functions) and data structures in the kernel. Some existing interfaces must be stabalized; that is, LxDM must mandate that things such as kmalloc() and kfree() must always function compatible to how they are specified. For example, kmalloc() allocates blocks of specific sizes, and may allocate a block larger than requested. This is fine; but it must allocate a block of at least what is requested. It may also understand other mode arguments (i.e. GFP_WTF) than LxDM mandates, if it understands all those that LxDM mandates as well.

To summarize, LxDM is about creating an ABI that will grow to accommodate new types of hardware and new features; but that will always be able to load and execute drivers written for older LxDM infrastructures. LxDM will specify symbols created for the LxDM project, as well as the operation of currently existing symbols. This will guarantee that any LxDM driver will always find the symbols it needs--and thus be loadable--by future kernels with future LxDM versions.