[LinuxPPS] multiple access to /dev/ppsN entries

[Bernhard Schiffner]

On Friday, 19. March 2010 12:33:33 George Spelvin wrote:
> > Good news!
> > Correct me please if I'am wrong: This blocking will be left when a new
> > result is there _and_ the using application is schedulded the next time
> > (means usually something below a millisecond later).
> 
> I don't quite understand.  The application is unblocked as part of the
> interrupt handler.  Of course, there is a delay between "scheduled to
> run" and "running".  Is that what you're referrinf to?
> 
> The question is really what you mean by "blocked".  If the processor
> was idle when the process became ready to run, it will be scheduled
> as part of the interrupt return a few microseconds later.
Yes, thanks for the explanation.

> >> The onle big *mistake* in my patch set was that I made *all* the
> >> parameters per-fd, but while nothing in the PPSAPI spec requires all
> >> users to have the same event set (and letting different readers use
> >> different ines is quite useful), a careful reading shows that it expects
> >> the offset values to be global.
> > 
> > Sorry I don't understand  these details exactly, Perhaps Miroslav
> > stumbled across this? (But it is quite sure not your patch causing his
> > problem.) " ...
> > I tried opening the same PPS device twice, one for assert events and
> > one for clear events, and only the later worked, so I'm assuming the
> > setting is per device instead of per open. If both capture same
> > events, it works fine.
> > ..."
> 
> That's something the current implementation does (the event mode is
> global), and I fixed because I thought it was stupid.
Ok.  +=2 (Miroslav and me)

> > George can you do me (and others) a big favour please and post the
> > patches to LKML and / or LinuxPPS?
> 
> Do you want the patches with the per-open offset?  Those are ready;
> making the offset global got stalled and I have to pick it up again.
I don't use the offset functionality of the interface.
Perhaps others want. (And it makes sense to me.)

Perhaps you split them: first "normal" read, second offset (global) if it's 
ready.

> > Does all events have a slope information? (IIR /dev/lpt interrupts only
> > at one slope)
> 
> According to the API, yes.  A given hardware device might not provide
> both types of events, but all events are of one type or the other.
OK, good.

> From a kernel point of view, I'd prefer to split the "assert" and
> "clear" into two devices, but that would make emulating the PPSAPI much
> more complicated.  (If enough other people think it's worth doing, I'll
> do it, but at the moment I haven't bothered because I figure there's no
> chance the changes would be accepted.)
> 
> Frankly, the PPS API is fairly badly designed.  But it's *a* standard,
> which is better than nothing.
Yes.
(I don't unterstand _why_ they do all the stuff with functioncalls etc.
IMHO there is no problem if you use /dev/pps as we intend now.)

Thanks a lot for these detailed explanations.


Bernhard