My apologies for the delayed response; I've recently switched email providers and this mailing list always seems to annoy our servers for some reason.
I'm also based in New Zealand and don't really travel all that much, so I'm not likely to get to a physical conference. Having said that, I would love to get more of the patches in the patchset included upstream where possible -- the main reason why it's based on the default branch rather than the stable branch is because some of the patches from past versions of the patchset have already been merged to default. This is also why I've structured it the way I have, with bugfixes separate from new features, and (theoretically at least) ordered by importance and intended merging order. (Though I've perhaps been less aggressive in reordering patches than I should have, to reduce churn.) I've also strived to introduce configure options or other easily togglable settings for some of the more niche or controversial functionality. This is also the reason why it's a patchset rather than a full fork, so that it should be easier to merge into upstream Mercurial. (And at least one other person has made a full fork available for the people who prefer that.) I've tried to minimise compatibility breakage and indeed in the current version of the patchset I don't think there is any hard breakage (beyond unavoidable changes to ioctls, which the readme and version detection addresses). As always, I welcome suggestions for changes to or alternate orderings of the patches that might make them easier to merge upstream, either in whole or in part. For the record, regarding the patches base/0017 and base/0018 that seem particularly in contention at the moment: they were originally submitted by Knud Baastrup (included in his series of patches to mailbox functionality, which I feel is critically important) -- I'm not sure if he's still around, but perhaps he could further explain the motivation? I do have some reservations about them as they do contradict the core Etherlab documented policy of requiring application-level locks when running multiple realtime tasks -- and my own applications use just one realtime task and don't use EoE so they do not require any additional locking. But they seemed valuable to retain specifically for the case of a pure userspace application that wants to use EoE, since in this scenario it is not possible to supply callbacks to provide the necessary locking for EoE (unless I've missed something?). This is the main reason that I have retained them, although I did rewrite them a couple of times to make the locking optional for RTDM applications, where it is counterproductive. I welcome alternative suggestions for handling these cases as well. I have not yet had time to fully review Graeme Foot's latest EoE patches, so I haven't integrated them yet, but they do seem like a step towards treating EoE as a first-class task explicitly managed by the application (as if they were a separate domain), which in turn could perhaps be extended to pure userspace applications. This might perhaps be another path towards integrating EoE in a way that doesn't require these additional lock patches. > -----Original Message----- > From: Graeme Foot > Sent: Tuesday, 6 March 2018 18:27 > To: Florian Pose <f...@igh.de>; etherlab-dev@etherlab.org > Subject: Re: [etherlab-dev] Community contribution > > Hi, > > I would also be interested in an etherlab related ethercat conference, but > it's > unlikely that I would be able to get to it. I'm based in New Zealand. > > My best chance of getting to that part of the world (though very small) is > that > I could be able to go to Hannover Messe in 2019, though that is probably too > far away. There is an even smaller chance I could get to the 2018 Hannover > Messe, but that may be too soon (23-27 April). > > Regards, > Graeme. > > > -----Original Message----- > From: Florian Pose > Sent: Monday, 5 March 2018 10:18 PM > To: etherlab-dev@etherlab.org > Subject: Re: [etherlab-dev] Community contribution > > Hello all, > > On Fri, Mar 02, 2018 at 10:58:54AM +0100, Esben Haabendal wrote: > > > Do main contributors (Florian Pose, Philipp Weyer, Gavin ...) have > > > an opinion on that ? > > > > I really hope they do, and hope they will participate in the > > discussion here. > > sure we have. ;-) > > The goal must be to maintain one source that as-many-as-possible users can > live with. I understand that the current situation (with different versions of > patchsets) is not satisfactory. > > From the IgH point-of-view we have the stable-1.5 branch that we see as > matured software and that we use heavily in our everyday projects. This > branch nearly contains everything *we* need (except for some native > drivers that are more up-to-date). > > The other side is (and this is what was the goal from beginning) that the > master (and moreover all other software within the EtherLab project) should > be useful for others, which is certainly is, but one can see from the > discussions and the patches, that it does not fit everyone's needs. > > The reason that I do not just pull the whole patchset in the default branch > (for example) is that I'm not hundred percent convinced of every single > patch (or at least I do not understand why it is necessary), others I don't > like > because they break compatibility. > > There is an idea in my mind that came up some time ago, and I think it would > make sense right now: What do you guys think about some kind of EtherCAT > conference? We should bring developers (physically) together taking two or > three days of time to discuss patches and opinions, make plans for the future > and work on integrating the patches. I'm thinking of a group of a handful > developers (maybe Gavin, Graeme, Esben, ... ) that are deeply involved. > > Naturally I would propose the IgH headquarters in Essen, Germany to be the > location. I don't know how hard it is for you to get here, or it is even > possible. > What I could also imagine, is some people here and some by video > conference, but I like the thought of meeting physically. > > What do you think about it? > > > -- > Best regards, > Florian > > ------------------------------------------------------------------------ > > Dipl.-Ing. (FH) Florian Pose > f...@igh.de > Tel.: +49 201 / 36014-13 > > Ingenieurgemeinschaft IgH > Gesellschaft für Ingenieurleistungen mbH Heinz-Bäcker-Str. 34 > D-45356 Essen > > Amtsgericht Essen HRB 11500 > USt-Id.-Nr.: DE 174 626 722 > Geschäftsführung: > - Dr.-Ing. T. Finke, > - Dr.-Ing. W. Hagemeister > Tel.: +49 201 / 360-14-0 > http://www.igh.de > > GnuPG key: CCA047CC 2007-12-18 [expires: 2022-01-31] > Fingerprint: 0081 4005 FE9F 73FF 4BDA A409 0011 4E20 CCA0 47CC > > ------------------------------------------------------------------------ > > _______________________________________________ > etherlab-dev mailing list > etherlab-dev@etherlab.org > http://lists.etherlab.org/mailman/listinfo/etherlab-dev _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
