netdev - Re: [PATCH net-next] ptp: increase the maximum number of clocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Mar 2013 19:51:20 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	Jiri Benc <jbenc@...hat.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] ptp: increase the maximum number of clocks

On Mon, Mar 25, 2013 at 05:08:55PM +0100, Jiri Benc wrote:
> On Sat, 23 Mar 2013 18:59:15 +0100, Richard Cochran wrote:
> > Jiri, do you want to work on making the number of clocks essentially
> > unlimited? If not, I can take a look at this, but not right away.
> 
> I'm currently thinking of using just /dev/ptp for all PHCs in the
> system and specifying the desired network device (ifindex, likely)
> by an ioctl as the very first operation. What do you think? If this
> is viable, I can try to implement it.

While that might work for the PTP ioctls, it won't for the main
clock_gettime/settime/adjtime call. As you wrote below, these take a
dynamic clockid_t (which comes from a file descriptor), and so each
device needs its own, unique file system node.

For better or worse, we are stuck with char devs, unless we want to
redo the clock_xyz API. I certainly don't want to. We can have over a
million PTP clocks on a single major number. That should be enough.

IIRC, it is possible to grow the range of minor numbers
incrementally. Perhaps you could take a look at that?

Thanks,
Richard
 
> As for netlink, I don't see how to do that without reimplementing the
> whole kernel<->user space timer API. The API expects clockid_t which
> is either a const (a new constant wouldn't help, we can have multiple
> PHCs in the system), or a dynamic value. There is no space for more
> dynamic values as far as I can see, all combinations of the three lower
> bits are already defined. It seems we're left with file descriptors.
> 
>  Jiri
> 
> -- 
> Jiri Benc
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html