User Space Emulation of Devices

User Space Emulation of Devices

[Phil Thompson]

Without going into the gory details, I have a requirement for a device
driver that does very little apart from pass on the open/close/read/write
"requests" onto a user space application to implement and pass back to the
driver.

Does anything like this already exist?

Thanks,
Phil

Re: User Space Emulation of Devices

[joseph.bueno]

Phil Thompson wrote:
> 
> Without going into the gory details, I have a requirement for a device
> driver that does very little apart from pass on the open/close/read/write
> "requests" onto a user space application to implement and pass back to the
> driver.
> 
> Does anything like this already exist?
> 
> Thanks,
> Phil
> -

Hi,

You may use pseudo-terminals (pty) to pass open/close/read/write/ioctl requests
to user space.

Your monitoring application opens master side of the pseudo terminal and
monitored application opens slave side.

Ptys are mainly used to redirect serial device communications (tty) to user
space but they can also be used to emulate other types of devices.
Check pty man pages for details.

Hope this helps
--
Joseph Bueno
NetClub/Trader.com

Re: User Space Emulation of Devices

[Pavel Machek]

Hi!

> Without going into the gory details, I have a requirement for a device
> driver that does very little apart from pass on the open/close/read/write
> "requests" onto a user space application to implement and pass back to the
> driver.
> 
> Does anything like this already exist?

Something like that which would also pass ioctl()s would be *very*
welcome.
								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: User Space Emulation of Devices

[Oliver Neukum]

Am Mittwoch, 12. September 2001 12:28 schrieb Pavel Machek:
> Hi!
>
> > Without going into the gory details, I have a requirement for a device
> > driver that does very little apart from pass on the open/close/read/write
> > "requests" onto a user space application to implement and pass back to
> > the driver.
> >
> > Does anything like this already exist?
>
> Something like that which would also pass ioctl()s would be *very*
> welcome.
> 								Pavel

How do you pass an ioctl ? If any parameter is a pointer you actually need a 
complex protocol for passing memory content to make it useful.

	Regards
		Oliver

Re: User Space Emulation of Devices

[H. Peter Anvin]

Followup to:  <20010912214444Z271795-760+12170@vger.kernel.org>
By author:    Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>
In newsgroup: linux.dev.kernel
> 
> How do you pass an ioctl ? If any parameter is a pointer you actually need a 
> complex protocol for passing memory content to make it useful.
> 

You need a parameter marshalling system; however, they do exist.  It
might actually be that the best way to deal with this is to make a
general module framework and compile a specific module to marshall the
parameters of the device you want to emulate.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: User Space Emulation of Devices

[Alan Cox]

> > How do you pass an ioctl ? If any parameter is a pointer you actually need a 
> > complex protocol for passing memory content to make it useful.
> > 
> You need a parameter marshalling system; however, they do exist.  It
> might actually be that the best way to deal with this is to make a
> general module framework and compile a specific module to marshall the
> parameters of the device you want to emulate.

Didnt someone announce a kernel mode corba daemon a while back ?

Re: User Space Emulation of Devices

[Dwayne C. Litzenberger]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Thu, Sep 06, 2001 at 09:25:08AM +0100, Phil Thompson wrote:
> Without going into the gory details, I have a requirement for a device
> driver that does very little apart from pass on the open/close/read/write
> "requests" onto a user space application to implement and pass back to the
> driver.
> 
> Does anything like this already exist?

I think the HURD does something like this.  I can't say any more than that,
since I haven't actually run it yet. :-)

-- 
Dwayne C. Litzenberger - dlitz@dlitz.net

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: User Space Emulation of Devices

[Tim Jansen]

On Thursday 13 September 2001 00:34, Alan Cox wrote:
> Didnt someone announce a kernel mode corba daemon a while back ?

korbit.sourceforge.net

bye...

Re: User Space Emulation of Devices

[Jeremy Elson]

Hi,

Coincidentally enough I was about to release a system called FUSD
which does exactly what you describe - marshal the arugments of a
system call into a message and proxy it to userspace.  The source will
be out in a couple of days, but for now here's a link to some
incomplete documentation:

http://www.circlemud.org/~jelson/software/fusd

FUSD (pronounced "fused", as in fusing kernel with userspace) 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.

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.



>Followup to: <20010912214444Z271795-760+12170@vger.kernel.org>
>By author: Oliver Neukum <Oliver.Neukum@lrz.uni-muenchen.de>
>In newsgroup: linux.dev.kernel
>>
>> How do you pass an ioctl ? If any parameter is a pointer you actually need a
>> complex protocol for passing memory content to make it useful.
>>
>
>You need a parameter marshalling system; however, they do exist. It
>might actually be that the best way to deal with this is to make a
>general module framework and compile a specific module to marshall the
>parameters of the device you want to emulate.

Re: User Space Emulation of Devices

[Tim Jansen]

On Thursday 13 September 2001 10:25, Phil Thompson wrote:
> The best approach I found (for my purposes anyway) was the one used by the
> ALSA OSS emulator (and strace as well?) that uses weak & strong symbols in
> a pre-loaded shared library to intercept system calls to the device I
> wanted to handle in user space.
> I'd be surprised if this technique was suitable as a generic approach.

Unfortunately not for writing device drivers in user space because the 
library inherits the user id from the application - you have to be root to 
access hardware.

bye...

RE: User Space Emulation of Devices

[Phil Thompson]

> -----Original Message-----
> From: Pavel Machek [mailto:pavel@suse.cz]
> Sent: 12 September 2001 11:28
> To: Phil Thompson; 'linux-kernel@vger.kernel.org'
> Subject: Re: User Space Emulation of Devices
> 
> 
> Hi!
> 
> > Without going into the gory details, I have a requirement 
> for a device
> > driver that does very little apart from pass on the 
> open/close/read/write
> > "requests" onto a user space application to implement and 
> pass back to the
> > driver.
> > 
> > Does anything like this already exist?
> 
> Something like that which would also pass ioctl()s would be *very*
> welcome.

The best approach I found (for my purposes anyway) was the one used by the
ALSA OSS emulator (and strace as well?) that uses weak & strong symbols in a
pre-loaded shared library to intercept system calls to the device I wanted
to handle in user space.

I'd be surprised if this technique was suitable as a generic approach.

Phil