Back to
main page

 
Last updated Sep. 17 1999 by Morten Rolland

The pros and cons of a userspace "modem"

An ongoing debate is what functionality should go into a kernel and which should not. I believe a wise man said something similar to (this is not a correct quote, and I have no references, sorry):

Improving software is best done by removing bits and pieces of it that is not needed, until no more can be removed.

My personal belief is that this is a good tactic for the Linux kernel, as a smaller kernel is more easilly debugged and verified. The 'i4lfax' project is basically a userspace project. There are many arguments in favour of a userspace project, and a few against (comments welcome):

pros

  1. Avoids kernel bloat, better stability of overall system
  2. Easier development cycle (no crashes, can use debugger, simple to set up a dry-run and catching debugging output)
  3. No need to sync to kernel (development/stable) or release the software as patches to various kernel releases
  4. Patent problems will be localized to the userspace program only, and as the program can have a license different from the GPL, distribution problems like the ones caused by the GPL can be avoided
  5. Very easy to port to other OS
  6. New and/or exotic IO-devices can be supported easilly, even if they don't exist in every kernel, or is userspace only.

Comments: Personally, I think (1) and (4) are the most fundamental and important arguments against a kernelspace implementation. If (4) turns out to be a problem once inside the kernel, a lot of work will be needed to revert to a userspace solution if evicted from the kernel.

Secondly (2) and (3) and (6) are very good news to the programmers, as it reduces development effort and helps concentrate effort where needed.

Thirdly (5) is good news to the open source movement in general, and a larger user base will help improve the quality of the software.

Cons

  1. Latency and regular sample delivery
  2. Ease of use and interoperablity

Comments: It seems like (1) will not be a problem, or it can be dealt with by improving the real-time scheduler in Linux, for the benefit of not only the 'i4lfax' project.

The ease of use part is of unknown importance; the pty/tty interface can probably be made sufficiently automatic to be viable as a modem emulation device.

The SLIP/PPP kernel-layer is also rumoured to work over ptys. This is untested, but should work, and should be fixed if it doesn't. Some changes to the kernel may thus be needed to properly support a modem in a userspace process, but they should be small end generic.

Morten Rolland