On Sun, Jul 28, 2013 at 10:31:47PM +0200, Henrik Nordström wrote: > sön 2013-07-28 klockan 07:02 +0300 skrev Stefan Kristiansson: > > > The biggest difference is that the arch spec defines a seperate register > > (xMMUPR) which holds a table of protection bits, and the PP INDEX field > > of the pte is used to pick out the "right" protection flags from that. > > In our Linux port on the other hand, it has been chosen to not follow > > this and embed the protection bits straight into the pte (which of > > course is perfectly fine as it was designed for software tlb reload). > > So, the question is, should we change Linux to be compliant with the > > arch specs definition of the ptes and start using a PP index field or > > change the arch spec to allow usages of the Linux definition? > > Is there any pros/cons for the different approaches? >
You tell me ;) Perhaps the whole original idea behind the PP INDEX field was to save bits in the PTE and make it flexible, but IMO it just makes things more complicated. > What approach do other architectures use? The closest thing I could find to the PP INDEX field in any other architecture is the ACC bit field in sparc v8 [1], but if I understand things correctly, that is mapped to a static table. And if I read the ARM code right, I think they have seperate definitions for the PTEs on the Linux and hardware side, residing in different memory areas. I don't think we should do it like that though. Stefan [1] http://www.sparc.org/standards/V8.pdf, page 248 _______________________________________________ Linux mailing list Linux@lists.openrisc.net http://lists.openrisc.net/listinfo/linux