Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> On Thu, 2009-12-03 at 22:42 +0100, Gilles Chanteperdrix wrote: >>>> Wolfgang Mauerer wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> Wolfgang Mauerer wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 03.12.2009, at 14:14, Gilles Chanteperdrix >>>>>>> <[email protected] >>>>>>> > wrote: >>>>>>> >>>>>>>> Wolfgang Mauerer wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Gilles Chanteperdrix wrote: >>>>>>>>>> Wolfgang Mauerer wrote: >>>>>>>>>>> So that means, in essence, that you would accept probabilistic >>>>>>>>>>> algorithms in realtime context? >>>>>>>>>> Ah, today's troll! >>>>>>>>> though it seems that I have to replace Jan this time ;-) >>>>>>>>>> As I think I explained, the use of a seqlock in real-time context >>>>>>>>>> when >>>>>>>>>> the seqlock writer only happens in linux context is not >>>>>>>>>> probabilistic. >>>>>>>>>> It will work every time the first pass. >>>>>>>>> I still don't see why it should succeed every time: What about >>>>>>>>> the case that the Linux kernel on CPU0 updates the data, while >>>>>>>>> Xenomai accesses them on another CPU? This can lead to >>>>>>>>> inconsistent data, and they must be reread on the Xenomai side. >>>>>>>> Yeah, right. I was not thinking about SMP. But admit that in this >>>>>>>> case, >>>>>>>> there will be only one retry, there is nothing pathological. >>>>> that's right. Which makes it bounded again, so it's maybe >>>>> the best way to go. >>>>>>>>> I'm asking because if this case can not happen, then there's >>>>>>>>> nothing left to to as I have the code already at hand. >>>>>>>> You have reworked the nucleus timers handling to adapt to this new >>>>>>>> real-time clock ? >>>>>>> Nope. Sorry, I was a bit unclear: I'm just referring to the gtod >>>>>>> syscall that does the timer handling, Not any other adaptions. >>>>>> Ok, but what good is the gtod syscall if you can not use it as a time >>>>>> reference for other timing related services? >>>>> it suffices for our project's current purposes ;-) >>>>> >>>>> But it's certainly not the full solution. Before, we >>>>> should have a decision wrt. the design issues, but I >>>>> won't be able to continue working on this before >>>>> mid of next week to look at the changed required for timer >>>>> handling and come up with code. >>>> Ok. To summarize what we have said, here is how I see we could implement >>>> the NTP synchronized clock fully, and portably: >>>> 1- allocate at nucleus init time, an area in the global sem heap for >>>> this clock house-keeping >>>> 2- add an event to the I-pipe patch when vsyscall_update is called >>>> 3- implement the nucleus callback for the I-pipe event which copies >>>> relevant data with our own version of seqlock called with hardware irqs >>>> off, to the area allocated in 1 if the current clock source is the tsc >>>> 4- rework the nucleus clocks and timers handling to use these data >>>> 5- pass the offset of the data allocated in 1 to user-space through the >>>> xnsysinfo, or xnfeatinfo structures >>>> 6- rework clock_gettime to use these data, using the user-space >>>> counterpart of the seqlock used in 3 >>>> >>>> The real hard work is 4, and note that something which I did not mention >>>> yesterday, is that we not only have to change the real-time clock >>>> implementation, we also have to change the monotonic clock >>>> implementation, otherwise the two clocks will drift apart. >>>> >>>> I think making such a change now is unreasonable. >>>> >>>> So, solution 1, we can implement 5, passing a null offset to mean that >>>> the support is unimplemented by the kernel and not even use it in >>>> user-space. Keeping the work for later in the 2.5 life cycle. >>>> >>>> Solution 2, we keep this change for 3.0. >>>> >>>> Solution 3, we implement a way to read that clock without synchronizing >>>> the nucleus with it (that is, everything but 4). One way to do this, >>>> which I do not like, is to add a dummy clock id to the posix skin, for >>>> instance CLOCK_LINUX_NTP_REALTIME, and implement the clock reading for >>>> that clock id in clock_gettime. This clock id, when passed to any other >>>> service, causes EINVAL to be returned, making it clear that this clock >>>> can not be used for anything else. Note that if we do that, even if we >>>> implement the full support later, we will have to keep that dummy clock >>>> id forever. >>>> >>>> My preference goes to solution 1. Philippe, what do you think? >>> Way too late for this kind of change; 2.5.0 will be out this month. >>> Timer related issues are prone to introduce nasty subtle regressions. >>> Let's plan this for 3.0. The earlier 2.5.0 will be out, the earlier 3.0 >>> will start. >> No, this was not about turning the nucleus timer handling upside down >> for 2.5.0, this was first of all about establishing the required kernel >> to user space ABI for 2.5. Can we agree on the latter? > > Ok. It is solution 1 then. In order to get things evolving more easily > than my first solution, here is what is proposed. > > We define a structure which will be shared between kernel and user, > which contains all data exported by kernel to user, as well as flags > indicating which member of the structure is available. The definition of > the struct for 2.5.0 will be: > > struct xnshared { > unsigned long long features; > }; > > This struct will be allocated in the global sem heap, and features will > be null for the time being. > > Every time we need to share some data between kernel and user (including > for the ntp support), we will add data to the structure, and use a > "features" bit to mean that the data are available from kernel. It will > work as long as we add data from release to release and never remove it.
...while features can still be removed by clearing their bits again. Sounds good to me. > > So, for 2.5.0, the xnshared structure will be allocated, but the > features member will be null. We will pass the offset of this structure > in the global sem heap in the sysinfo structure. Ack. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list [email protected] https://mail.gna.org/listinfo/xenomai-core
