[LinuxPPS] multiple access to /dev/ppsN entries

[Bernhard Schiffner]

On Friday, 19. March 2010 11:20:14 George Spelvin wrote:
> > George's patch makes a read() possible every time.
> > So  a  select(...) on  *readfds makes  no sense. The only way is to
> > "fill" *exceptfds by the driver when receiving a new timestamp.
> 
> No, it doesn't.  Read blocks until there's a new timestamp; the simplest
> way to view it is "cat /dev/ppsX".

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).

@Ben: Is this good enough for your purposes?

> Also, both the read() and ioctl() accesses use the same "read pointer", so
> select()/poll() can also be used to wait until there's new ioctl() data.
> 
> What my patch set also did was use the poll() feature to make the
> *ioctl* non-blocking; it can have the timeout eliminated and
> greatly simplified to always return the most recent timestamp,
> immediately.  (The sequence numbers let you identify duplicates
> very easily.)
This is what I experienced and was really happy to have.

> It does mean that implementing a get-pps with a timeout takes two
> system calls (poll + ioctl) rather than one, but I think gaining
> the ability to wait for a PPS event *or* a different event
> is hugely worth it.
YES!
 
> 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.
..."

George can you do me (and others) a big favour please and post the patches to 
LKML and / or LinuxPPS?

Neverthless some toughts:
Does all events have a slope information? (IIR /dev/lpt interrupts only at one 
slope)
If they don't provide: what to do next?
- use "assert" as standard (+)
- report "noslope" (~)
- leaving the field empty (-)
The question results from beeing able to do a simple (unconditional) cut -d" " 
-f3 etc.

The discussion about a peferable format seems to have vanished (/dev/time, 
Plan9 and perhaps others)
A suggestion:
Timestamp first, slope, eventnumber
This results from some personal experience merging mmiotraces with kernel 
printk() messages: it's avantageous to have a common format.


Caution:
1.) enneenne.com seems to have problems  today,
2.) I sent them mails by cc: but these mails didn't show up in the list.

Thanks in advance!


Bernhard