[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.
Indeed.
> 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.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
More information about the krbdev
mailing list