On Mon, Jun 7, 2021 at 2:02 PM Joao Martins <[email protected]> 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.
