Re: [RFC] Improvements to KCM prococol and notification mechanism
Simo Sorce <[email protected]> Thu, 04 Feb 2021 13:14:23 -0500
| Newsgroups | gmane.comp.encryption.kerberos.devel |
|---|---|
| Organization | Red Hat, Inc. |
| Message-ID | <[email protected]> |
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 _______________________________________________ krbdev mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev