J
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.
Huh?
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.
OK.
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
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> > 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.
Huh?
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.
OK.
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
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
