On Mon, Jun 7, 2021 at 2:02 PM Joao Martins <joao.m.martins@xxxxxxxxxx> wrote: [..] > > But naming aside, I was trying to get at was to avoid a second geometry value validation > > i.e. to be validated the value and set with a value such as DEVMAP_PTE, DEVMAP_PMD and > > DEVMAP_PUD. > > Sorry my english keeps getting broken, I meant this instead: > > But naming aside, what I am trying to get at is to remove the second geometry value > validation i.e. for @geometry to not be validated a second time to be set to DEVMAP_PTE, > DEVMAP_PMD or DEVMAP_PUD. > > > That to me sounds a little redundant, when the geometry value depends on what > > align is going to be used from. Here my metnion of @align refers to what's used to create > > the dax device, not the mmap() align [which can be lower than the device one]. The dax > > device align is the one used to decide whether to use PTEs, PMDs or PUDs at dax fault handler. > > > > So separate concepts, but still its value dependent on one another. At least unless we > > want to allow geometry values different than those set by --align as Jane suggested. > > > > And I should add: > > I can maintain the DEVMAP_* enum values, but then these will need to be changed in tandem > anytime a new @align value is supported. Or instead we use the name @geometry albeit with > still as an unsigned long type . Or rather than an unsigned long perhaps making another > type and its value obtained/changed with getter/setter. No, feel free to drop the enum and use an explicit "geometry" value for the vmemmap.
