Am 05.02.2013 um 01:29 schrieb Chris Morley: > > >> In any case LinuxCNC would remain, and depend on that package. The API used >> by LinuxCNC would change from 'current' to 'messaging' over time. Once that >> is complete, the dividing line between the two packages would also be the >> realtime boundary; there would be no need anymore for the LinuxCNC package >> proper to be in any way dependent on a particular realtime OS or RTAPI >> except for the messsaging API. That means LinuxCNC per se would be in >> principle free to use any UI, and a much wider range of underlying OSes. >> >> I see quite a few potential users for such a HAL/RTAPI package; of course it >> isnt impossible right now, as you say, but the fact that it is integrated >> with linuxcnc brings not only baggage with it. I would think few people >> outside the Linuxcnc community are actually aware of separate HAL/RTAPI use >> is possible, and would consider using it standalone. >> >> Maybe Peter can chip in here with an idea for another use case we recently >> discussed offline. >> >> The HAL/RTAPI package would inherit most of the build complexity as now >> LinuxCNC is pretty much standard userland code; reworking an HAL/RTAPI only >> build process is a little bit easier than the whole of LinuxCNC. >> >> I also see some benefit on the relicensing them (without having properly >> researched that yet, though) - I would think that HAL/RTAPI - given it has >> much fewer authors - could be more easily morphed into a less restrictive >> license enabling the use of several key packages needed for the messaging >> API. Eventually the whole of LinuxCNC must be relicensed IMO, but at least >> we have a starting point. >> >> So this effort would roughly contain HAL, RTAPI, HAL-capable UI tools like >> gladevcp, comp, plus the future messaging-based API. >> >> As a tentative name I propose 'MachineKit' or 'Realtime MachineKit', so the >> baby has a name which doesnt break the tongue and conveys a bit of intent >> and functionality. >> >> - Michael >> > > I agree that this is direction we should go.
... > Would your messaging scheme be just for HAL or would it replace NML ? Eventually HAL messaging will replace NML. Besides communicating individual signal values, it needs to be able to convey compound objects (C structs if you will, for instance to replace the EMCStatus access). I'll lay out in separate mail how that's going to work and how UI's are impacted (or rather not). The actual addition to hal_lib.c per se is fairly minimal, the rest is a userland code affair. > and licensing is holding back the messaging isn't it ( I mean aside from time) yes. Actually I'd rate the HAL messaging effort substantially lower than the remapping effort in LOC, and it is very generic in nature. That is under the condition we can rely on a messaging layer with all required language bindings readily available for us, as well as the serialisation/deserialisation layer. Taking the Stevens book, firing up the editor and starting from scratch with 'fd = socket(AF_NET, ...)' is just not going to cut it. > As far as whether it gets put in v2.5, master or linuxcnc3, I think a lot of > that comes down to how much > freedom you need to do what you want. I started Gscreen in V2.5 till it was > clear I needed to go to > master to change the things that needed to be changed to make it work > satisfactory. > > But if talking fixing licensing then your probably talking V3.0 Well in the minimum I would want to remove the roadblock to start work on the machinekit messaging extension. As I laid out, this is explicitly intended not to break compatibility with current builds based on the shared memory paradigm. The current hal.h interface is going to remain, and has to remain anyway - if only internally to machinekit far down the road. But relicensing only HAL/RTAPI+friends is only part of the story, eventually the whole codebase should morph to use HAL messaging. Even if the network messaging layer is a license boundary, the library(ies) of the access layer for GPL2-only parts remain an issue. There is a remote chance a liberally licensed version of ZermoMQ becomes available eventually, and it could be used to cover the UI/task/interp part in case relicensing stalls for this part. I would absolutely hate to have do this. It is a kludge, and lots of work. > So are you thinking: > > 1) new realtime options (almost done) > 2) pull out HAL and friends as it's own package promote it to the free world > :) yes, that's the executive summary. > 3) decide on the direction for the CNC controller > which sounds like re licence, more modularisation, and more separating of > user and realtime code (motion) Not sure I want to decide it; but what I surely want to do is to revamp the structure that such things become less messy or an option at all. Your above note on halui is key in point. - Michael > > Chris M > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
