Hi Thomas, Thanks for all these suggestions! On Thu, Dec 1, 2022 at 5:38 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > [...] (everything snipped here makes perfect sense). > > You have to be aware, that the rodata space needs to be page granular > while text and data can really aggregate below the page alignment, but > again might have different alignment requirements. I don't quite follow why rodata space needs to be page granular. If text can go below page granular, rodata should also do that, no? > > So you need a configuration mechanism which allows to specify per type: > > - Initial mapping type (RX, RWX, RW) > - Alignment > - Granularity > - Address space restrictions [...] > > Step 1: > These steps are really helpful. Thanks! [...] > > For text that's obviously module_write_text(), but for the [ro]data > mappings memcpy() is still fine. For the rodata mapping you need > set_memory_ro() right in the module prepare stage and for the > ro_after_init_data() you do that after the module init function returns > success, which is pretty much what the code does today. I guess this is related to rodata needs to be page granular? But I don't think I got the idea. Do we allow rodata and rwdata share the same 2MB page? ro_after_init_data seems trickier. > > Step 5: > [...] > > Linus once said: > > "Bad programmers worry about the code. Good programmers worry about > data structures and their relationships." > > He's absolutely right. Here is my version of it: > > The order of things to worry about: > > 1) Problem analysis > 2) Concepts > 3) Data structures and their relationships > 4) Code > > #1 You need to understand the problem fully to come up with > concepts > > #2 Once you understand the problem fully you can talk about > concepts to solve it > > #3 Maps the concept to data structures and forms relationships > > #4 Is the logical consequence of #1 + #2 + #3 and because your > concept makes sense, the data structures and their > relationships are understandable, the code becomes > understandable too. > > If any of the steps finds a gap in the previous ones, then you > have to go back and solve those first. > > Any attempt to reorder the above is putting the cart before the horse > and a guarantee for failure. Thanks for these advices! They would help me for many years. > > Now go back and carefully read up on what I wrote above and in my > previous mail. > > The previous mail was mostly about #1 to explain the problem as broad as > possible and an initial stab at #2 suggesting concepts to solve it. > > This one is still covering some aspects of #1, but it is mostly about #2 > and more focussed on particular aspects of the concept. If you look at > it carefully then you find some bits which map to #3 but still at the > conceptual level. > > Did I talk about code or implementation details? > > Not at all and I'm not going to do so before #1 and #2 are agreed > on. The above pseudo code snippets are just for illustration and I used > them because I was too lazy to write a novel, but they all are still at > the conceptual level. > > Now you can rightfully argue that if you stich those snippets together > then they form a picture which outlines the implementation, but that's > the whole purpose of this exercise, right? I guess I will do my homework, and come back with as much information as possible for #1 + #2 + #3. Then, we can discuss whether it makes sense at all. Does this sound like the right approach? Thanks, Song
