Re: [9fans] Bits of Plan 9 I wish were more popular...

Re: [9fans] Bits of Plan 9 I wish were more popular...

[erik quanstrom]

> The only issue is that I can't justify the time needed to write Plan 9
> drivers when a usable system already exists.
>
> > Still you could use 9vx to run plan9 on top of this system, that way you could maybe
> > migrate the system gradually.
>
> Unless vx32 can run real-time tasks (pretty sure it cannot) that's not
> much use.  Almost every bit of my code (all except a very thin command
> interface) is living in a loadable kernel module
>
> Don't you want Kalman filters in *your* OS kernel?

it seems suprising that it all runs in the kernel.
doesn't linux support real-time user processes?

- erik

Re: [9fans] Bits of Plan 9 I wish were more popular...

[Digby Tarvin]

On Thu, Jul 03, 2008 at 08:51:22AM -0400, erik quanstrom wrote:
> > The only issue is that I can't justify the time needed to write Plan 9
> > drivers when a usable system already exists.
> >
> > > Still you could use 9vx to run plan9 on top of this system, that way you could maybe
> > > migrate the system gradually.
> >
> > Unless vx32 can run real-time tasks (pretty sure it cannot) that's not
> > much use.  Almost every bit of my code (all except a very thin command
> > interface) is living in a loadable kernel module
> >
> > Don't you want Kalman filters in *your* OS kernel?
>
> it seems suprising that it all runs in the kernel.
> doesn't linux support real-time user processes?

It all depends on how strict your interpretation of real-time is.

The situation with Linux is similar to what I recall existed in SVR4,
There is 'real-time domain' scheduling, the POSIX.4 API for finer timing
control, and you can lock processes in core to prevent them from
swapping/paging... its ok if there is a bit of buffering to smooth out
the occasional delay, such as for multimedia applications, but if
delayed response to an interrupt could cause your reactor to go
critical then it probably isn't good enough. Unix just wasn't designed
for hard real-time.

The standard solution used in LinuxRT and RTAI is essentially to run
Linux on top of a real-time kernel. Your real-time applications then
run in real-time on the same machine as your Linux apps with some
limited ability to comunicate with them, but don't have access to Linux
system calls or libraries.

Putting your time critical code into the kernel is another way to
get more predictable response times - particularly if you can do the
time critical stuff in an interrupt service routine. but again you
forgo the normal Linux/User API and library access, and you have to
be careful of drivers and other parts of the kernel which may be
masking interrupts.

It is a bit like the attempts to retrofit multi-tasking to DOS.
You are better off designing somethign that has real-time in mind
from the start and then retrofitting the Unix/Linux compatability.

Regards,
DigbyT
--
Digby R. S. Tarvin                                          digbyt(at)digbyt.com
http://www.digbyt.com

Re: [9fans] Bits of Plan 9 I wish were more popular...

[Joel C. Salomon]

On Thu, Jul 3, 2008 at 12:25 PM, Digby Tarvin <digbyt@acm.org> wrote:
> You are better off designing somethign that has real-time in mind
> from the start and then retrofitting the Unix/Linux compatability.

As the real-time additions to Plan 9 show, that isn't strictly
necessary -- if the kernel code base is sufficiently small and
well-designed.

--Joel

[9fans] Bits of Plan 9 I wish were more popular...

[Joel C. Salomon]

In response to the recent troll invasion:

I've just started work at a CNC router manufacturer, doing control
system programming.  The machine I'm using to test & prototype control
algorithms is Linux with the RTAI real-time patches and I/O card
drivers from the Comedi project.  The way to get a hard-real-time
process?  Build and install a ——ing kernel module!  As regards
communicating with arbitrary I/O cards Comedi isn't completely
useless, merely so painful it should be called Tragedi.

The prototyping machine is completely in my control, so I could use
Plan 9 — if I could justify writing the drivers.  Trouble is, the
driver for the D/A converter comes with Comedi and someone here has
already written a driver for the quadrature encoder.  So I'm stuck on
that end.  I got a lot of programming done in school using acme under
Plan 9; for the first time I realize why the lunix world likes
Eclipse.  ☹

On the production side, I'm about to inherit the code base for the
controller.  Takes instructions from a PC host via USB and fans them
out to separate motion controller units.  And passes information back.
 And tinkers with the data stream when that's called for.  No
operating system.  I miss libthread — I may yet port it for a later
version, if I'm going to be contributing much to the controller rather
than just maintaining it.

One change I probably will make (since the data structures are all
scheduled for radical change) is in the transport.  The current code
base has corresponding structures on different machines declared with
the various "packed" pragmas and transported with byte-order-swapping
— when I get my hands on it it'll be done with proper marshalling.

So there we have it: sane real-time, decent hardware interfaces,
libthread, and data transport methods.  Plan 9 still has plenty to
teach the rest of the computing world.

--Joel

Re: [9fans] Bits of Plan 9 I wish were more popular...

[Steve Simon]

> ... Trouble is, the
> driver for the D/A converter comes with Comedi and someone here has
> already written a driver for the quadrature encoder.
So you have the source for the quadrature encoder, and a DAC cannot be thar complex can it? why not email Comedi and ask them for card programming info.

Having said that I do sympathise, its difficult to work out the trade off between
putting up with systems you find unplesant and hoping you don't use them much,
or puttin the effort to redesign them.

Still you could use 9vx to run plan9 on top of this system, that way you could maybe
migrate the system gradually.

> I miss libthread — I may yet port it for a later
> version, ...

Russ has a version of libthread for windows on his web page.

-Steve

Re: [9fans] Bits of Plan 9 I wish were more popular...

[Joel C. Salomon]

On Wed, Jul 2, 2008 at 7:13 PM, Steve Simon <steve@quintile.net> wrote:
> So you have the source for the quadrature encoder, and a DAC cannot be thar complex can it? why not email Comedi and ask them for card programming info.

Comedi is an Open Sores project to unify the worlds data acquisition
devices under one driver model.  It's about as good a model as fits
the Linux Way™ of these things, and there's enough sample code
included to make it feasible to bring up a new card fairly quickly.
Rather have Comedi drivers than some random vendor's conceptions of
how to program the device, but it's nothing like a simple write(2) to
/dev/analogout0/channel1.

The only issue is that I can't justify the time needed to write Plan 9
drivers when a usable system already exists.

> Still you could use 9vx to run plan9 on top of this system, that way you could maybe
> migrate the system gradually.

Unless vx32 can run real-time tasks (pretty sure it cannot) that's not
much use.  Almost every bit of my code (all except a very thin command
interface) is living in a loadable kernel module

Don't you want Kalman filters in *your* OS kernel?

> Russ has a version of libthread for windows on his web page.

Do you mean libtask?  That could be helpful too, but the system uses
interrupts so cannot entirely be run as cooperative multithreading.

The discipline of thinking in terms of channels. even if the
implementation has gone a-gley, is proving useful too.

--Joel