Simple cache implementation

[vmezzela]

A few days ago I had issues while using klp-build due to git fetch being really slow. Hence I implemented this simple cache to avoid fetching every time.

Please let me know if that's something that you think is worth merging. If so, I will reiterate over the proposed PR to see if there's something that can be done better.

One thing that might be added is a global --no-cache option that disables the cache.

[fgyanz]

Hi @vmezzela, I like the idea!

One thing that might be added is a global --no-cache option that disables the cache.

I'd have it as a configuration variable, a long with the option to set the frequency (maybe? Not sure about this one)
Also, maybe it would be useful to run the git-fetch with a timeout. AFAIK we all have high-speed connections and the servers are quite fast too, so fetching shouldn't take more than 4-5minutes.

[vmezzela]

I'd have it as a configuration variable

I don't know, I imagine I would use it in case I notice something weird and I want to bypass the cache.

But indeed, someone might still want to not use it at all. So both options are valid an not mutual exclusive.

[vmezzela]

Hi, I implemented a @cache_func decorator that can cache the function result persistently across different runs. I guess it make sense to use it only on some functions and perhaps it need to be further adjusted. Let's say that this is just a POC now.

This totally replaced the initial implementation, hence I squashed all the commits in one.

I found it really useful when checking for symbols. For instance, if we happen to run setup different times to adjust something, we would check the symbols over and over even if they didn't change (hence wasting time). This is particularly annoying when the affected module is vmlinux and checking the symbols takes even more time than usual.

Also, @fgyanz I introduced both the config option and the --no-cache argument to control the cache.

[marcosps]

Well, IMHO, this is not really a problem that happens everyday, so I'm not sure if this would be used in the end, but I understand that it can make someone's day product, even if this happens once in a year :)

[vmezzela]

Well, IMHO, this is not really a problem that happens everyday, so I'm not sure if this would be used in the end, but I understand that it can make someone's day product, even if this happens once in a year :)

Are you referring to git fetch being slow?

Because the PR no longer address that issue only, but also others. As for my previous comment it also is useful when running a command that does an expensive computation and we need to rerun it again to adjust some parameters (I mentioned running setup/extract on a livepatch that affects vmlinux): with this feature, that expensive computation will just be cached making it all faster.

But as said, this is just a POC, we should decide where to use the decorator and where not.