Rainer Weikusat wrote:

You'll probably be decorated, at least in mind, by the
GPL-avoidance-acrobats from the gadget industry,

This is certainly not my intent. All of our Linux software
will be open-sourced, probably with a BSD type license. For
us at least it is not a matter of license but of productivity.
We have to do a lot of drivers and could not possibly get them
all into the kernel.

I have written a short article about this work
and posted it at http://www.linuxtoys.org/usd/UserSpaceDrivers.html

Well, why do you use kernel level drivers at all? For your application, a

I am working on a Linux based robot controller and had to solve
the problem of creating a lot of Linux device drivers quickly.
My solution was to create a couple of real, but thin, device drivers
and use them as the front-end to a user-space driver daemon that
did the real work. I have written a short article about this work
and posted it at http://www.linuxtoys.org/usd/UserSpaceDrivers.html

I would appreciate any feedback that might make the article easier
to read, but I would _especially_ appreciate feedback on the two
kernel modules.

Jan Kandziora <jjj at (no spam) gmx.de> wrote:
But I don't think character devices are really "user friendly", except if
the user should use tools normally tied to such character devices, like
e.g. use minicom with it or dd a firmware file to it.
OK, but this might come down to personal preference. I like the
idea of telling a stepper motor to step 2000 steps with the command:
echo "2000" > /dev/dp/step_count

To do the equivalent with, for example, unix sockets would
probably require an API to the sockets, so a .so library to
hide the details of the socket.

Hi

I am working on a Linux based robot controller and had to solve
the problem of creating a lot of Linux device drivers quickly.
My solution was to create a couple of real, but thin, device drivers
and use them as the front-end to a user-space driver daemon that
did the real work. I have written a short article about this work
and posted it at http://www.linuxtoys.org/usd/UserSpaceDrivers.html

I would appreciate any feedback that might make the article easier
to read, but I would _especially_ appreciate feedback on the two
kernel modules.

My solution was to create a couple of real, but thin, device drivers
and use them as the front-end to a user-space driver daemon

Well, why do you use kernel level drivers at all? For your application, a
user level dameon with a unix socket or pty interface would suffice...
A valid point. We could have. There were several reasons why we

You'll probably be decorated, at least in mind, by the
GPL-avoidance-acrobats from the gadget industry,
This is certainly not my intent. All of our Linux software will

Linux 2.6.31 supports CUSE (character device in user space).
Yeah, CUSE/FUSE was our "PLAN A" approach. But I could not get

Grant Edwards <invalid at (no spam) invalid.invalid> wrote:

I don't really understand what "API to the sockets" would be.
All the languages I know of already have socket APIs.

Can you think of a common Linux daemon that offers only a
socket as the application interface? I can not.

Most daemons that use sockets, such as DBus, do not allow raw
access to the socket and instead offer library that "hides"
the socket from the application. While not required, hiding
the socket behind a library is the most common Linux approach
and an approach I do not want to use.

Grant Edwards <invalid at (no spam) invalid.invalid> wrote:
In any case, I'd probaly use IF_INET sockets instead of Unix
sockets. Then you can use netcat.
echo "step 2000" | nc -q0 $dpHost $dpCmdPort
That assumes all commands go to the same port number.
Writing something like netcat for unix-domain sockets would
also be pretty trivial.

Grant, you are right and have given me pause to rethink my
whole approach.

There are, or will be, about 30 device driver to do and each
of these has several configuration parameters. This many
devices would make mapping from robot peripheral to TCP socket
number quite a problem. But unix sockets would not have this
problem.

So, with your socket approach ...

ROBOT DRIVER FEATURE SET
- Unix domain socket with good bidirectional data flow
- Good bidirectional flow control
- Broadcast (not intrinsic, but easy to do in the daemon)

- No root privledge to to set up
- No mucking with kernel modules

Jan Kandziora wrote:
Well, why do you use kernel level drivers at all? For your application, a
user level dameon with a unix socket or pty interface would suffice...
A valid point. We could have. There were several reasons why we
did not. Making the device look like a real device is, I think, a
little more user friendly.

Well, ok. You like to hide the fact the whole communication is done in

Also, neither sockets nor pty devices offer
a broadcast capability which is required, nor do they offer the flow
control that I wanted.

Broadcast? What do you mean? Concurrent access?

But I don't think character devices are really "user friendly", except if
the user should use tools normally tied to such character devices, like
e.g. use minicom with it or dd a firmware file to it.
OK, but this might come down to personal preference. I like the

Broadcast? What do you mean? Concurrent access?
Same for flow control. Please explain.
If you haven't already, would take a few minutes to read the

I don't really understand what "API to the sockets" would be.
All the languages I know of already have socket APIs.
Can you think of a common Linux daemon that offers only a

In any case, I'd probaly use IF_INET sockets instead of Unix
sockets. Then you can use netcat.
echo "step 2000" | nc -q0 $dpHost $dpCmdPort
That assumes all commands go to the same port number.
Writing something like netcat for unix-domain sockets would
also be pretty trivial.

- No root privledge to to set up
- No mucking with kernel modules

How big a hassle that last one turns out to be probably depends
on which kernel APIs you end up using. Some of them (e.g. the
tty layer) seem to be rather fluid.

OK, but this might come down to personal preference. I like the
idea of telling a stepper motor to step 2000 steps with the command:
echo "2000" > /dev/dp/step_count

Sure, it's personal preference, but I think not mine alone. The thing above

To do the equivalent with, for example, unix sockets would probably
require an API to the sockets, so a .so library to hide the details
of the socket. But not just one .so file since to be well received
I'd need to write binding for my API for lots of languages -- PHP,
Perl, ... This does not sound "minimalist" at all.

Um, you have an ascii protocol above... It's a piece of cake just sending

Jan Kandziora <jjj at (no spam) gmx.de> wrote:
Broadcast? What do you mean? Concurrent access?
Same for flow control. Please explain.
If you haven't already, would take a few minutes to read the
article at the URL in the original post.

The idea of device broadcast is not usually visible but is in the
/dev/input subsystem. An example in the article shows how to see
this. Robot sensors (my interest) also need a broadcast system.

From what I've read, it's concurrent access. The node may be opened muliple

I did not mention "concurrent access" but perhaps this refers to
the idea of broadcast? One writer and many concurrent readers?

As any reader must be known to the writer in your case, I would not call

Both named pipes and pty devices allow you to write up to 4K bytes
when just one end is open. I wanted to block all writes until
both ends were open. "Flow control" to me refers to select() in
a way. I need bidirectional transfer (ruling out named pipes)
and wanted flow control to flow in both directions up to the
select() on each side. One side being the driver daemon and the
other side being the high-level robot application. I hope this
makes sense.

It does. Your previous design choices, especially the one to allow arbitrary

But is being able to avoid socat worth the hassle of having to
compile and install the fanout and proxy modules?

[...]

I think I'm at the point where I need to ask this of our potential
customer base. This is not something you and I need to decide.

Although not your customer (yet?), I'm an electrical engineer (and

My first rule is to avoid any vendor supplied software as most times it's
just crap (root access required for the whole system, 100% processor load
while doing nothing, doing X11 calls from a driver program etc.) Basically,
most hardware vendors do not know anything about reasonable software
design.
I kind of agree with the above. My company will publish the protocol

If avoiding vendor software is not possible, I at least try to avoid kernel
modules. The kernel is a big, single program and driver A from company AA
may require 2.6.20, while driver B from company BB requires 2.6.25. As a
customer *not* ordering 1000 Pcs of the hardware, you are out of luck.
Company AA will redo their piece of crap in a year or whenever they like
to.
Again I agree. The active word in the article title is "minimalist".

Devices with binary only drivers (regardless if userspace or kernelspace)
and without a matching protocol description are outruled at all.
We publish everything except the Verilog source that goes into the

For kernel modules, at least *all* of the companies doing a kernel module
for my hardware must behave nice.
I am trying to behave nice, at least as much as I know how.