On Tue, 2020-06-23 at 19:13 -0400, Tejun Heo wrote: > Hello, Rick. > > On Mon, Jun 22, 2020 at 02:22:34PM -0700, Rick Lindsley wrote: > > > I don't know. The above highlights the absurdity of the approach > > > itself to > > > me. You seem to be aware of it too in writing: 250,000 "devices". > > > > Just because it is absurd doesn't mean it wasn't built that way :) > > > > I agree, and I'm trying to influence the next hardware design. > > However, > > I'm not saying that the hardware should not segment things into > however many > pieces that it wants / needs to. That part is fine. > > > what's already out there is memory units that must be accessed in > > 256MB > > blocks. If you want to remove/add a GB, that's really 4 blocks of > > memory > > you're manipulating, to the hardware. Those blocks have to be > > registered > > and recognized by the kernel for that to work. > > The problem is fitting that into an interface which wholly doesn't > fit that > particular requirement. It's not that difficult to imagine different > ways to > represent however many memory slots, right? It'd take work to make > sure that > integrates well with whatever tooling or use cases but once done this > particular problem will be resolved permanently and the whole thing > will > look a lot less silly. Wouldn't that be better? Well, no, I am finding it difficult to imagine different ways to represent this but perhaps that's because I'm blinker eyed on what a solution might look like because of my file system focus. Can "anyone" throw out some ideas with a little more detail than we have had so far so we can maybe start to formulate an actual plan of what needs to be done. Ian
