On Tue, Aug 06, 2019 at 05:02:03PM -0700, Paul Walmsley wrote: > The rationale is to encourage others to start laying the groundwork for > future Sv48 support. The immediate trigger for it was Alex's mmap > randomization support patch series, which needs to set some Kconfig > options differently depending on the selection of Sv32/39/48.
Writing a formal todo list is much better encouragement than adding dead code. Th latter has a tendency of lingering around forever and actually hurting people. > > > but actively harmful, which is even worse. > > Reflecting on this assertion, the only case that I could come up with is > that randconfig or allyesconfig build testing could fail. Is this the > case that you're thinking of, or is there a different one? If that's the > one, I do agree that it would be best to avoid this case, and it looks > like there's no obvious way to work around that issue. randconfig or just a user thinking bigger is better and picking it. > > Even if we assume we want to implement Sv48 eventually (which seems > > to be a bit off), we need to make this a runtime choice and not a > > compile time one to not balloon the number of configs that distributions > > (and kernel developers) need to support. > > The expectation is that kernels that support multiple virtual memory > system modes at runtime will probably incur either a performance or a > memory layout penalty for doing so. So performance-sensitive embedded > applications will select only the model that they use, while distribution > kernels will likely take the performance hit for broader single-kernel > support. Even if we want to support Sv39 only or Sv39+Sv39 the choice in the patch doesn't make any sense. So better do the whole thing when its ready than doing false "groundwork".
