Jeff Layton <jlayton@xxxxxxxxxx> wrote: > The typical way to do this would be to rebrand the existing FSCACHE > Kconfig symbols into FSCACHE_OLD and then build the new fscache > structure such that it exists in parallel with the old. That, there, is nub of the problem. You can't have parallel cachefiles drivers: There's a single userspace interface (/dev/cachefiles) and only one driver can register it. You would need to decide at compile time whether you want the converted or the unconverted network filesystems to be cached. > You'd then just drop the old infrastructure once all of the fs's are > converted to the new. You could even make them conflict with one another in > Kconfig too, so that only one could be built in during the transition period > if supporting both at runtime is too difficult. > > This approach of disabling everything is much more of an all-or-nothing > affair. It may mean less "churn" overall, but it seems less "nice" > because you have an interval of commits where fscache is non-functional. > > I'm not necessarily opposed to this approach, but I'd like to better > understand why doing it this way was preferred. I'm trying to avoid adding two parallel drivers, but change in place so that I can test parts of it as I go along. David
