Bob Smith schrieb:
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
is not a commonly expected way to work with device nodes. It more
resembles /proc or /sys nodes. To a device node, nearly all users expect
they once open the node, then continously talk to it. I would also not
expect to talk in ascii, except for terminal devices.
You are correct. This is a poor example. Let's divide a driver into

The thing above could be implemented through FUSE, though -- "owfs" does it
that way. Google it, it pretty much does the same hardware muxer job your
program does.
When I first started into all of this I pinned my hopes on FUSE. FUSE

Um, you have an ascii protocol above... It's a piece of cake just sending
name+SPACE+value+LF through a TCP connection, any reasonable high-level
language could do that by printf() or similar. It would even be
network-enabled ootb.
Right. All character drivers have the problem of how to send data

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
it "broadcast". Broadcast means "shouting out into space". For that, it
needs a common media, e.g. shared memory or a network with broadcast
features.
OK. Let's call it "fanout" instead of broadcast.

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
programs to control anything like they want to, narrow it down to that.
Jan, the reason I posted originally was to improve on what I did,

[...]
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 programs to control anything like they want to, narrow it down
to that.
Jan, the reason I posted originally was to improve on what I did,
to find a better way. If you had to write 30 or so device drivers
quickly and with minimal code, how would you do it?

Hmm. The thing which let *me* shudder most is the kernel module required.

I have a H+/DXR3 MPEG decoder card in my private PC as a
TV-out device. It has some I?C chips on it and requires a
kernel driver. Ok, nearly unavoidable in that case.

What's kind of horrible is that the I?C subsystem of the Linux
kernel had an incompatible change with *any* version since
2.6.15 until now. That means the people doing the DXR3 driver
had to do some tweaking and testing to their sources *15*
times.