J
Jiri Baum:
> > That can be done. Either by some trick (above), or by simply coding a
> > function that copies registers to private map, calls plc_update() and
> > copies private map to registers.
Curt Wuollet:
> Just blue sky, but I was thinking that a common IO proc could provide
> those abstractions in a uniform way so that "drivers" (the broad term)
> wouldn't have to be lplc specific.
That may well still happen. Especially if there's a common way of handling things between kernel-space and user-space, one io module might handle any number of kernel drivers.
> I'm still stuck on what to do with protocols. Many require some sort of
> engine unto themselves.
Exactly. In a lot of cases, I suspect, interfacing with the SMM will be the easy part.
Especially if we present the plc_set() function as "write to register" and plc_get() as "read from register".
Jiri Baum:
> > > > Where a group of devices are accessed in a similar way, they could
> > > > all be handled using one I/O process (for example, one IO module
> > > > could handle any number of 8255-based cards).
Curt Wuollet:
> > > Yes that would be good if possible.
> > I think your dio48 code could be adapted for that - up to 9 or 10 chips
> > would be easy, beyond that some of the parsing and string handling
> > would have to be done differently.
> I would hope we could be more elegant than my hackings.
Some of the code would be changed into loops (rather than 8 lines of the same thing), but apart from that I don't see a problem with it...
We are all hacking. (*Vorlon sound effect*)
> > > Since a great deal of making this thing truly useful is supporting
> > > everything under the sun, I see making it easy to add IO types as
> > > mission critical ( oops, fell into ITspeak, sorry )
> > True. Often, I expect, it'll be a question of taking an existing,
> > similar driver and changing it, but we should definitely make it as
> > easy as possible. But no easier - that's the hard part.
> It's so hard to encourage support and so easy to discourage it, it may
> take an Einstien.....
Well, that was the quote I was referring to
I guess we'll just have to do the best we can - no-one can expect more of us, and we'd be remiss if we did less.
Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> > That can be done. Either by some trick (above), or by simply coding a
> > function that copies registers to private map, calls plc_update() and
> > copies private map to registers.
Curt Wuollet:
> Just blue sky, but I was thinking that a common IO proc could provide
> those abstractions in a uniform way so that "drivers" (the broad term)
> wouldn't have to be lplc specific.
That may well still happen. Especially if there's a common way of handling things between kernel-space and user-space, one io module might handle any number of kernel drivers.
> I'm still stuck on what to do with protocols. Many require some sort of
> engine unto themselves.
Exactly. In a lot of cases, I suspect, interfacing with the SMM will be the easy part.
Especially if we present the plc_set() function as "write to register" and plc_get() as "read from register".
Jiri Baum:
> > > > Where a group of devices are accessed in a similar way, they could
> > > > all be handled using one I/O process (for example, one IO module
> > > > could handle any number of 8255-based cards).
Curt Wuollet:
> > > Yes that would be good if possible.
> > I think your dio48 code could be adapted for that - up to 9 or 10 chips
> > would be easy, beyond that some of the parsing and string handling
> > would have to be done differently.
> I would hope we could be more elegant than my hackings.
Some of the code would be changed into loops (rather than 8 lines of the same thing), but apart from that I don't see a problem with it...
We are all hacking. (*Vorlon sound effect*)
> > > Since a great deal of making this thing truly useful is supporting
> > > everything under the sun, I see making it easy to add IO types as
> > > mission critical ( oops, fell into ITspeak, sorry )
> > True. Often, I expect, it'll be a question of taking an existing,
> > similar driver and changing it, but we should definitely make it as
> > easy as possible. But no easier - that's the hard part.
> It's so hard to encourage support and so easy to discourage it, it may
> take an Einstien.....
Well, that was the quote I was referring to
I guess we'll just have to do the best we can - no-one can expect more of us, and we'd be remiss if we did less.
Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
