top-level design


Thread Starter

Jiri Baum

NOTE: I'm putting about three emails together and replying to them, so I apologise if I mix up the attributions.

> > Curt Wuollet:
> > > There will have to be some task responsible for translating the reads
> > > and writes to and from a char driver, for example, to the memory map.

Jiri Baum:
> > That's OK. I was thinking linuxPLC-native drivers, which don't need any
> > such translation: they just `know' the input and write it to the shared
> > memory (or read an output from the shared memory and make it so).

Curt Wuollet:
> The reasons I see a go-between for the drivers are that it allows us to
> use exixting drivers

Yup, of course.

> and others to use our drivers for other purposes.

I wouldn't worry too much about that; if someone else wants them, they can modify it to suit whatever they want. Whatever `general purpose' thing we do would likely just be inconvenient for *everyone*.

> Last, and this is a biggie, the IO task should be in user space and many
> drivers will need to be in kernel space for interrupts etc.

Yes - but some drivers won't need that (eg a serial-protocol driver can be all user-space). Anything that needs a kernel driver will need a user-space task to interface between the kernel part and the SMM (and that task may or may not be common for several kernel-space drivers).

Curt Wuollet:
> > > It will have to know how to deal with all the various types of I/O
> > > which might be as diverse as user space networking drivers or a 8255
> > > kernel module.

Jiri Baum:
> > I'd favour separate tasks for separate drivers, for simplicity's sake.

Curt Wuollet:
> We can do it that way, or we could have a library that we add to
> incrementally.

Separate tasks are easier; for instance, they are almost automatically reenterant.

> I have been thinking of using a scan divisor so fast I/O is hit every
> scan and slow I/O every nth scan to allow for the speed difference.

Separate tasks do this automatically. (Asynchronous unless otherwise specified.)

Curt Wuollet:
> > > I see two main processes, one on either side of the mmap. All the
> > > nastiness would be in the I/O task and the solver/UI side would be
> > > clean. That's what I'm coding for.

Jiri Baum:
> > Hopefully, all the sides would be clean :)

Curt Wuollet:
> Clean in this case would be architecture independent.

I was thinking more `elegant and orthogonal design'.

(Architecture-independent would be nice, too, but elegant and orthogonal is more important, IMO. At least for now.)

> Spinlocks and such would raise Hell with determinism.


We're definitely going to need semaphores (spinlocks); perhaps not right now, but soon enough. I don't think there's any way around it.

Curt Wuollet:
> > > I would entertain the idea of a subtask for each I/O driver, but that
> > > has some ugly aspects. How were you thinking the thing would work?

Jiri Baum:
> > What ugly aspects were you thinking of? Because a subtask for each I/O
> > driver was exactly what I was thinking... (I'd love to know if there's
> > something I missed.)

Curt Wuollet:
> Init, mapping, and map coherence come to mind.


Init (of the shared map) is the task of the memory manager, and mapping is not a problem provided the interface is clean.

As for map coherence, I don't think you can ever truly synchronise two separate physical I/O devices, so we'll never need coherence between two
different drivers; depending on the device/protocol, we might only be able
to synchronise on a per-octet level or something, anyway.

> That's why I was thinking about a scan divisor scheme as it allows us to
> be synchronous.
> If we do completely seperate tasks, theres a lot of IPC to keeping
> coherent. I don't know, maybe PLC's simply ignore timing differences and
> hope for the best or chain everything (slow).

I was thinking for the first iteration, simply ignore timing differences and see what happens. No doubt for many applications that'll be sufficient.

Where it isn't sufficient, we'll at least have a visible target to code for; the IPC won't be all that hairy (a bank of semaphores should do it).

Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

LinuxPLC mailing list
[email protected]