lc_get(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

lc_get(9) πŸŽ€

okay so welcome to the Kernel API Manual, bestie β€” this is the lc_get(9) page and it's lowkey iconic ✨

πŸ’– NAME πŸ’–

lc_get β€” get element by label, maybe change the active set πŸ’…

🌸 SYNOPSIS 🌸

struct lc_element * lc_get (struct lru_cache *lc , unsigned int enr );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • lc β€” the lru cache to operate on, bestie. that's the main character here.
  • enr β€” the label to look up. yes, the one you're hunting for πŸ”

✨ DESCRIPTION ✨

So lc_get finds an element in the cache, increases its usage count, "touches" it, and returns it. periodt. πŸ’…

In case the requested number is not present, it needs to be added to the cache. because of that, it is possible that an other element becomes evicted from the cache. in either case, the user is notified so he is able to e.g. keep a persistent log of the cache changes, and therefore the objects in use. fr fr, this is your heads-up moment 🫢

🎁 Return values 🎁

  • NULL β€” The cache was marked LC_STARVING, or the requested label was not in the active set and a changing transaction is still pending (lc was marked LC_DIRTY). Or no unused or free element could be recycled (lc will be marked as LC_STARVING, blocking further lc_get operations). not the vibe, but it's important 😭
  • pointer to the element with the REQUESTED element number β€” in this case, it can be used right away. slay, go off πŸ‘‘
  • pointer to an UNUSED element with some different element number β€” where that different number may also be LC_FREE.

In this case, the cache is marked LC_DIRTY, so lc_try_lock will no longer succeed. the returned element pointer is moved to the "to_be_changed" list, and registered with the new element number on the hash collision chains, so it is possible to pick it up from lc_is_used. up to "max_pending_changes" (see lc_create) can be accumulated. the user now should do whatever housekeeping is necessary, typically serialize on lc_try_lock_for_transaction, then call lc_committed(lc) and lc_unlock, to finish the change. literally the whole little transaction ritual 🧚

πŸ”₯ NOTE πŸ”₯

The user needs to check the lc_number on EACH use, so he recognizes any cache set change. no skipping the vibe check on this one, bestie β€” each use means each use πŸ™ˆ

πŸ’œ SEE ALSO πŸ’œ

Kernel file ./lib/lru_cache.c:


and that's the whole page, bestie: source ./lib, October 2026, lc_get(9) β€” Kernel API Manual edition πŸŽ€βœ¨πŸ«Ά

πŸ“¦ where this page comes from