Hi,
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.
Best,
Jer
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:
>http://www.circlemud.org/~jelson/software/fusd
>
>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,
>Jeremy
>
>--------
>
>
>WHAT IS FUSD?
>=============
>
>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
>counterparts.
>
>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
>drivers.
>
>For more information, please see the comprehensive documentation in
>the 'doc' directory.
>
> Jeremy Elson <jelson@circlemud.org>
> Sensoria Corporation
> September 28, 2001
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:15 EST