On Thu, 2010-09-23 at 21:36 +0100, Alan Cox wrote:

quoted

   So as far as the POSIX standard is concerned, offering a clock id
   to represent the PHC would be acceptable.

But completely useless as you may have more than one entirely different
time managed by PTP and in which you are not master but must work with
the timebases provided.

I don't see how this is a problem, as it exposes the multiple hardware
clocks via different posix clock ids. So in the boundary clock case, you
can configure which side is the client and which side is the master in a
config file and the PTPd will appropriately steer them individually.

quoted

    /sys/class/timesource/<name>/id
    /sys/class/ptp/ptp_clock_X/id

    Note: I am not too sure that this is exactly what people imagined,
          but it is my best understanding so far. I gleaned two
          different ideas about where to offer the clock id. In order
          to keep just one way, I will be happy to remove the less
          popular one.

I see no fix proposed for the race condition I pointed out. This doesn't
work.

So, if I recall this was: "How do you keep the module from unloading
while its being used?" 

There may need to be proper locking for unregistering the posix clock_id
on module unload, but I don't think we need a use-count to prevent the
module from being unloaded.

My question would be: How do we handle a USB network device ($14.99 now
with PTP!) being unplugged? We can't say "Sorry! That's in use!". So we
note the hardware is gone, and return the proper error code.

Or am I missing something else?

quoted

   If the Linux system time is synchronized to the PHC via the PPS

To which PHC we can have several

quoted

   + Intel IXP465
     - Auxiliary Slave/Master Mode Snapshot (optional interrupt)
     - Target Time (optional interrupt)

And about 40 already supported by char driver interface clocks and rtcs
in the kernel...

And those char driver interfaces are all subtly different.

I actually recently submitted an RFC to expose the RTC devices via the
posix clock/timer interface, because working with the RTC hardware
device directly is terrible for managing alarm interrupts. 

For instance, you easily run into the case where your TV recording
application programs an alarm to record your favorite show at 8pm. Then
your backup script programs an alarm to wake up at 2am to do your
nightly backups. Your box suspends and the next morning, you're missing
your favorite show!

I'd say the inability to have multiple clocks and the race condition
because of the clockid stuff leaves the proposal dead in the water.

It also ignores the existing APIs we have floating around attached to
devices.

You need to make one small important change. You need to take the POSIX
crap about enumerating things out and shoot it, bury it at a crossroads
and sprinkle holy water on it.

We agree the list-by-name stuff isn't the way to go. :)

Drop the clockid_t and swap it for a file handle like a proper Unix or
Linux interface. The rest is much the same

	fd = open /sys/class/timesource/[whatever]

	various queries you may want to do to check the name etc

	fclock_adjtime(fd, ...)
	

The posix interface is fundamentally flawed. It only works for staticly
enumerable objects. Unix avoided that forty years ago by making the
identifier a handle which immediately cures all your object lifetime
problems in one swoop.

So, I don't really see how that's so different from what is being
proposed. The clock_id is dynamically assigned per registered clock, and
exposed via the sysfs interface from ptp hardware entry.

The only difference is the open/close reference counting, which I don't
think is necessary here (since we can't always keep the hardware from
going away).

thanks
-john