[etherlab-dev] Community contribution

Mon Mar 19 09:59:41 CET 2018

Hello,

Yes, I am still around - I am actually working together with Esben Haabendal here in Denmark.

The patches base/0017 and base/0018 is not related to the other mailbox patches. I agree in your reservations about these patches and that we need to work towards a better solution that can fit us all.

Best regards
Knud Baastrup

-----Original Message-----
From: Gavin Lambert <gavin.lambert at tomra.com> 
Sent: 16. marts 2018 02:03
To: Graeme Foot <Graeme.Foot at touchcut.com>; Florian Pose <fp at igh.de>; etherlab-dev at etherlab.org
Cc: Knud Baastrup <kba at deif.com>
Subject: RE: [etherlab-dev] Community contribution

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 <fp at igh.de>; etherlab-dev at 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 at 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
> fp at 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 at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-dev