[ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Jeremy Elson]

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

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Jeremy Elson]

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

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Pavel Machek]

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.

This should be forwared to linmodem list... Killing all those
binary-only modem drivers from kernel modules would be good
thing... Hmm, and maybe we can just hack telephony API over ltmodem
and be done with that. That would be good.
								Pavel

-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Jeremy Elson]

Pavel Machek writes:
>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.
>
>This should be forwared to linmodem list... Killing all those
>binary-only modem drivers from kernel modules would be good
>thing... Hmm, and maybe we can just hack telephony API over ltmodem
>and be done with that. That would be good.
>								Pavel

Hi,

Perhaps I don't understand how linmodems work to understand well
enough how FUSD would apply - do you talk to linmodems through the
serial driver?  If so, sounds like a good application - but we might
still have the same problem with binary-only drivers as the
user-to-kernel message format used by FUSD may change over time.
(Indeed, it's already changing relative to v1.0 in response to
some of the mail I've gotten in the past few days.)

Best,
Jer

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Mike Fedyk]

On Tue, Oct 02, 2001 at 03:37:53PM -0700, Jeremy Elson wrote:
> Pavel Machek writes:
> >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.
> >
> >This should be forwared to linmodem list... Killing all those
> >binary-only modem drivers from kernel modules would be good
> >thing... Hmm, and maybe we can just hack telephony API over ltmodem
> >and be done with that. That would be good.
> >								Pavel
> 
> Hi,
> 
> Perhaps I don't understand how linmodems work to understand well
> enough how FUSD would apply - do you talk to linmodems through the
> serial driver?  If so, sounds like a good application - but we might
> still have the same problem with binary-only drivers as the
> user-to-kernel message format used by FUSD may change over time.
> (Indeed, it's already changing relative to v1.0 in response to
> some of the mail I've gotten in the past few days.)
> 

That's not good.

If there's one part of the kernel API that shouldn't change, this (or
something like it) should be it...

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Pavel Machek]

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.
> >
> >This should be forwared to linmodem list... Killing all those
> >binary-only modem drivers from kernel modules would be good
> >thing... Hmm, and maybe we can just hack telephony API over ltmodem
> >and be done with that. That would be good.
[snip]
> Perhaps I don't understand how linmodems work to understand well
> enough how FUSD would apply - do you talk to linmodems through the
> serial driver?  If so, sounds like a good application - but we might

Yep. And linmodem driver does signal processing, so it is big and
ugly. And up till now, it had to be in kernel. With your patches, such
drivers could be userspace (where they belong!). Of course, it would be 
very good if your interface did not change...
								Pavel

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Eric W. Biederman]

Pavel Machek <pavel@Elf.ucw.cz> writes:

> 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.
> > >
> > >This should be forwared to linmodem list... Killing all those
> > >binary-only modem drivers from kernel modules would be good
> > >thing... Hmm, and maybe we can just hack telephony API over ltmodem
> > >and be done with that. That would be good.
> [snip]
> > Perhaps I don't understand how linmodems work to understand well
> > enough how FUSD would apply - do you talk to linmodems through the
> > serial driver?  If so, sounds like a good application - but we might
> 
> Yep. And linmodem driver does signal processing, so it is big and
> ugly. And up till now, it had to be in kernel. With your patches, such
> drivers could be userspace (where they belong!). Of course, it would be 
> very good if your interface did not change...

I don't see how linmodem drivers apply.  At least not at the low-level
because you actually have to driver the hardware, respond to interrupts
etc.  On some of this I can see a driver split like there is for the video
card drivers, so the long running portitions don't have to be in the kernel.

I actually don't see what devices could be done in user space with
this context except possibly forwarding device calls across the
network.

Eric

linmodems (was Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices)

[Jeff Garzik]

On 7 Oct 2001, Eric W. Biederman wrote:
> Pavel Machek <pavel@Elf.ucw.cz> writes:
> > Yep. And linmodem driver does signal processing, so it is big and
> > ugly. And up till now, it had to be in kernel. With your patches, such
> > drivers could be userspace (where they belong!). Of course, it would be 
> > very good if your interface did not change...

> I don't see how linmodem drivers apply.  At least not at the low-level
> because you actually have to driver the hardware, respond to interrupts
> etc.  On some of this I can see a driver split like there is for the video
> card drivers, so the long running portitions don't have to be in the kernel.

My best guess for a Linux winmodem solution for Linux is three pieces:
The existing Lucent (and other) hardware work (by Pavel/Richard/Jamie/others?)
Rogier Wolff's user space serial driver code, and
A work called "modem" by a now-deceased scientist at SGI(IIRC).  Alan
pointed me to the last piece.  'modem' handles up to 14.4k speed, and
supports some error correcting protocols we all remember from the BBS
days.

Just need someone to glue those pieces together... and you have a
winmodem driver with the proper portions in userspace, and the proper
portions in kernel space.

	Jeff

Re: linmodems (was Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices)

[Pavel Machek]

Hi!

> My best guess for a Linux winmodem solution for Linux is three pieces:
> The existing Lucent (and other) hardware work (by Pavel/Richard/Jamie/others?)
> Rogier Wolff's user space serial driver code, and
> A work called "modem" by a now-deceased scientist at SGI(IIRC).  Alan
> pointed me to the last piece.  'modem' handles up to 14.4k speed, and
> supports some error correcting protocols we all remember from the BBS
> days.
> 
> Just need someone to glue those pieces together... and you have a
> winmodem driver with the proper portions in userspace, and the proper
> portions in kernel space.

One of students here was/is working on the glue; it is non-trivial as
'modem' is obfuscated with coroutines.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Pavel Machek]

Hi!

> > Yep. And linmodem driver does signal processing, so it is big and
> > ugly. And up till now, it had to be in kernel. With your patches, such
> > drivers could be userspace (where they belong!). Of course, it would be 
> > very good if your interface did not change...
> 
> I don't see how linmodem drivers apply.  At least not at the low-level
> because you actually have to driver the hardware, respond to interrupts
> etc.  On some of this I can see a driver split like there is for the video

You don't actually need interrupts -- you *know* when next sample arrives.
And port io is completely fine with iopl() ;-).
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: linmodems (was Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices)

[Tim Jansen]

On Monday 08 October 2001 04:37, Jeff Garzik wrote:
> A work called "modem" by a now-deceased scientist at SGI(IIRC).  Alan
> pointed me to the last piece.  'modem' handles up to 14.4k speed, and
> supports some error correcting protocols we all remember from the BBS
> days.

BTW There was someone working on v.34, but the page hasn't been updated in 
the last 18 months.. http://perso.enst.fr/~bellard/linmodem.html

> Just need someone to glue those pieces together... and you have a
> winmodem driver with the proper portions in userspace, and the proper
> portions in kernel space.

This is also important for USB modems. As Intel requests PC vendors to stop 
including serial ports in 2002 and linux-compatible USB modems are quite hard 
to find it will be really difficult to get an external modem for new 
computers. Almost every new USB modem uses either the ST7554 or the Connexant 
HCF chipset, and at least the ST7554 is controllerless. 

bye...

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Jeremy Elson]

On Fri, 5 Oct 2001, Pavel Machek wrote:
> Yep. And linmodem driver does signal processing, so it is big and
> ugly. And up till now, it had to be in kernel. With your patches, such
> drivers could be userspace (where they belong!). Of course, it would be 
> very good if your interface did not change...

FUSD's user-kernel interface won't change spuriously, but it sometimes
will need to change as features are added.  Some such changes are
already in the works.

The fact that FUSD provides a semi-stable binary interface for servicing
device-file callbacks isn't really FUSD's design goal as much as it is an
accidental side effect.  Making a stable binary interface for kernel
device drivers is the objective of, say, UDI (I think).  The purpose of
FUSD is just to be able to proxy the callbacks to userspace.

Best,
Jer

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Eric W. Biederman]

"Pavel Machek" <pavel@suse.cz> writes:

> Hi!
> 
> > > Yep. And linmodem driver does signal processing, so it is big and
> > > ugly. And up till now, it had to be in kernel. With your patches, such
> > > drivers could be userspace (where they belong!). Of course, it would be 
> > > very good if your interface did not change...
> > 
> > I don't see how linmodem drivers apply.  At least not at the low-level
> > because you actually have to driver the hardware, respond to interrupts
> > etc.  On some of this I can see a driver split like there is for the video
> 
> You don't actually need interrupts -- you *know* when next sample arrives.
> And port io is completely fine with iopl() ;-).

But DMA? You are talking about what amounts to a sound card driver.
And since in the cases that burn cpu time you have to process raw
sound samples into modem data, you need to shift a fair amount of
data. inb and outb just don't have the bandwidth.  So you need a
kernel side component that drives the hardware to some extent.

Additionally you still don't need a FUSD driver for that case.  All
you need is to have is a ptty.  Because that is what modem drivers
are now.  And the ptty route has binary and source compatiblity
to multiple unix platforms.

Eric

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Pavel Machek]

Hi!

> > > > Yep. And linmodem driver does signal processing, so it is big and
> > > > ugly. And up till now, it had to be in kernel. With your patches, such
> > > > drivers could be userspace (where they belong!). Of course, it would be 
> > > > very good if your interface did not change...
> > > 
> > > I don't see how linmodem drivers apply.  At least not at the low-level
> > > because you actually have to driver the hardware, respond to interrupts
> > > etc.  On some of this I can see a driver split like there is for the video
> > 
> > You don't actually need interrupts -- you *know* when next sample arrives.
> > And port io is completely fine with iopl() ;-).
> 
> But DMA? You are talking about what amounts to a sound card driver.
> And since in the cases that burn cpu time you have to process raw
> sound samples into modem data, you need to shift a fair amount of
> data. inb and outb just don't have the bandwidth.  So you need a
> kernel side component that drives the hardware to some extent.

You need to push 8kHz/16bit, that's 16 kilobytes per second. Or maybe
you can sample at 11kHz, getting 20 kilobytes per second. Comfortably
done with inb/outb.

> Additionally you still don't need a FUSD driver for that case.  All
> you need is to have is a ptty.  Because that is what modem drivers
> are now.  And the ptty route has binary and source compatiblity
> to multiple unix platforms.

I do not think tty/pty pair does cut it for AT emulation. Can you
really emulate all neccessary features using pty/tty?
								Pavel
-- 
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Jamie Lokier]

Pavel Machek wrote:
> > Additionally you still don't need a FUSD driver for that case.  All
> > you need is to have is a ptty.  Because that is what modem drivers
> > are now.  And the ptty route has binary and source compatiblity
> > to multiple unix platforms.
> 
> I do not think tty/pty pair does cut it for AT emulation. Can you
> really emulate all neccessary features using pty/tty?

Perhaps.  Terminal modes & speeds & special lines and so on set on the
tty side can be seen on the pty side, although I think the pty is not
notified immediately so it has to poll if it wants to detect terminal
programs sending a BREAK signal and things like that.

I had a look at this about a year ago.  I remember that a couple of
small changes to the pty/tty layer would have been very handy to improve
the quality of serial port emulation, and that might be the thing to do.

-- Jamie

Re: [ANNOUNCE] FUSD v1.00: Framework for User-Space Devices

[Jamie Lokier]

Pavel Machek wrote:
> I do not think tty/pty pair does cut it for AT emulation. Can you
> really emulate all neccessary features using pty/tty?

Remember that if you go for a full user-space driver, you have to
duplicate the kernel's tty layer to emulate everything.  For full
compatibility, that means emulating all the ancient serial and tty
ioctls properly including Linux-specific ones, SYSV-style ones,
BSD-style ones etc.

That's already been done _and_ tested in the kernel over the years.
While repeating that in user space is possible, I suspect that a pty/tty
interface would end up providing better compatibility (in practice) for
all the different, special and ancient terminal programs.  In the cases
where pty/tty doesn't relay enough information to the pty side, we
should look at whether minor changes to the pty driver can fix that.

cheers,
-- Jamie