LKML Archive on
help / color / mirror / Atom feed
From: Jeremy Elson <>
Subject: Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices
Date: Mon, 01 Oct 2001 08:36:02 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


Sorry to follow-up to my own post.  A few people pointed out that
v1.00 had some Makefile problems that prevented it from building.
I've released v1.02, which should be fixed.


Jeremy Elson writes:
>On behalf of Sensoria Corporation, I'm happy to announce the first
>public release of FUSD, a Linux Framework for User-Space Devices.
>Briefly, FUSD lets you write user-space daemons that can respond to
>device-file callbacks on files in /dev.  These device files look and
>act just like any other device file from the point of view of a
>process trying to use them.  When the FUSD kernel module receives a
>file callback on a device being managed from user-space, it marshals
>the arguments into a message (including data copied from the caller,
>if necessary), blocks the caller, and sends the message to the daemon
>managing the device.  When the daemon generates a reply, the process
>happens in reverse, and the caller is unblocked.
>More information can be found at the official FUSD home page:
>I've pasted a portion of the README file below, which has a somewhat
>more detailed description of what FUSD is and does.  A much more
>comprehensive user manual is available on the web page (above).
>Best regards,
>FUSD (pronounced "fused") is a Linux framework for proxying device
>file callbacks into user-space, allowing device files to be
>implemented by daemons instead of kernel code.  Despite being
>implemented in user-space, FUSD devices can look and act just like any
>other file under /dev which is implemented by kernel callbacks.
>A user-space device driver can do many of the things that kernel
>drivers can't, such as perform a long-running computation, block while
>waiting for an event, or read files from the file system.  Unlike
>kernel drivers, a user-space device driver can use other device
>drivers--that is, access the network, talk to a serial port, get
>interactive input from the user, pop up GUI windows, or read from
>disks.  User-space drivers implemented using FUSD can be much easier to
>debug; it is impossible for them to crash the machine, are easily
>traceable using tools such as gdb, and can be killed and restarted
>without rebooting.  FUSD drivers don't have to be in C--Perl, Python,
>or any other language that knows how to read from and write to a file
>descriptor can work with FUSD.  User-space drivers can be swapped out,
>whereas kernel drivers lock physical memory.
>FUSD drivers are conceptually similar to kernel drivers: a set of
>callback functions called in response to system calls made on file
>descriptors by user programs.  FUSD's C library provides a device
>registration function, similar to the kernel's devfs_register_chrdev()
>function, to create new devices.  fusd_register() accepts the device
>name and a structure full of pointers.  Those pointers are callback
>functions which are called in response to certain user system
>calls--for example, when a process tries to open, close, read from, or
>write to the device file.  The callback functions should conform to
>the standard definitions of POSIX system call behavior.  In many ways,
>the user-space FUSD callback functions are identical to their kernel
>The proxying of kernel system calls that makes this kind of program
>possible is implemented by FUSD, using a combination of a kernel
>module and cooperating user-space library.  The kernel module
>implements a character device, /dev/fusd, which is used as a control
>channel between the two.  fusd_register() uses this channel to send a
>message to the FUSD kernel module, telling the name of the device the
>user wants to register.  The kernel module, in turn, registers that
>device with the kernel proper using devfs.  devfs and the kernel don't
>know anything unusual is happening; it appears from their point of
>view that the registered devices are simply being implemented by the
>FUSD module.
>Later, when kernel makes a callback due to a system call (e.g. when
>the character device file is opened or read), the FUSD kernel module's
>callback blocks the calling process, marshals the arguments of the
>callback into a message and sends it to user-space.  Once there, the
>library half of FUSD unmarshals it and calls whatever user-space
>callback the FUSD driver passed to fusd_register().  When that
>user-space callback returns a value, the process happens in reverse:
>the return value and its side-effects are marshaled by the library
>and sent to the kernel.  The FUSD kernel module unmarshals this
>message, matches it up with a corresponding outstanding request, and
>completes the system call.  The calling process is completely unaware
>of this trickery; it simply enters the kernel once, blocks, unblocks,
>and returns from the system call---just as it would for any other
>blocking call.
>One of the primary design goals of FUSD is stability.  It should
>not be possible for a FUSD driver to corrupt or crash the kernel,
>either due to error or malice.  Of course, a buggy driver itself may
>corrupt itself (e.g., due to a buffer overrun).  However, strict error
>checking is implemented at the user-kernel boundary which should
>prevent drivers from corrupting the kernel or any other user-space
>process---including the errant driver's own clients, and other FUSD
>For more information, please see the comprehensive documentation in
>the 'doc' directory.
> Jeremy Elson <>
> Sensoria Corporation
> September 28, 2001

  reply	other threads:[~2001-10-01 15:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-29  1:18 Jeremy Elson
2001-10-01 15:36 ` Jeremy Elson [this message]
2001-10-02 18:48   ` Pavel Machek
2001-10-02 22:37     ` Jeremy Elson
2001-10-02 22:44       ` Mike Fedyk
2001-10-05 18:51       ` Pavel Machek
2001-10-08  2:09         ` Eric W. Biederman
2001-10-08  2:37           ` linmodems (was Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices) Jeff Garzik
2001-10-08 12:19             ` Pavel Machek
2001-10-08 19:34             ` Tim Jansen
2001-10-08 12:20           ` [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices Pavel Machek
2001-10-13 21:57             ` Eric W. Biederman
2001-10-14  6:12               ` Pavel Machek
2001-10-15 12:34                 ` Jamie Lokier
2001-10-15 12:38                 ` Jamie Lokier
2001-10-10  3:55         ` Jeremy Elson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \
    --subject='Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).