[RFC] Improvements to KCM prococol and notification mechanism

Simo Sorce simo at redhat.com
Thu Feb 4 13:14:23 EST 2021

On Thu, 2021-02-04 at 12:53 -0500, Greg Hudson wrote:
> On 2/4/21 5:25 AM, Pavel Březina wrote:
> > The goal is to provide common interface that would yield a path on which
> > consumers can inotify, obviously other mechanisms could be use on other
> > platforms eg fswatch on Mac.
> I guess an application could always fall back to polling the file if the
> platform has no inotify equivalent.  It would be cheaper than polling
> the ccache.


> But what path would the KEYRING type return?  I took a look at the
> general notification mechanism in Linux 5.8 and it doesn't seem to go
> through the filesystem.

I think the keyring is fast enough that we can simply return an error
and client will fall back to polling.

> (MEMORY also can't satisfy the interface, but as long as it can return
> an error that's probably not a problem.)

We could return a memfd ... and then operations on a memory cache would
simply "touch" the memfd to trigger notifications, but an error will
also be fine for the time being, notifications on a memory ccache are
not terribly interesting...


Simo Sorce
RHEL Crypto Team
Red Hat, Inc

More information about the krbdev mailing list