On 11/10/2010 10:55 AM, Grant Likely wrote:
On Wed, Nov 10, 2010 at 11:53 AM, H. Peter Anvin<[email protected]> wrote:
On 11/10/2010 11:06 AM, Dirk Brandewie wrote:
On 11/10/2010 10:46 AM, H. Peter Anvin wrote:
On 11/10/2010 10:52 AM, [email protected] wrote:
The DTB's have been moved into the .init.data section.
Writeable? (As opposed to .init.rodata)?
That is what I remember from the conversation with Grant but I could be
mistaken. It is simple enough to move as long as the interested parties agree
:-)
Obviously. I'd like to see it readonly unless there is an explicit
reason not to, of course.
Definitely it should be ro
So I am a little confused (no big surprise :-)
objdump -h vmlinux shows in part:
3 .rodata 000d61b8 c1358000 01358000 00359000 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 __init_rodata 00003a90 c1450be0 01450be0 00451be0 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .init.text 0002b297 c1488000 01488000 00489000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 .init.data 0001e5e0 c14b32a0 014b32a0 004b42a0 2**5
CONTENTS, ALLOC, LOAD, DATA
There is no .init.rodata section that I can find.
It seems like correct place to park the DTB with the other init data in
.init.data. section by adding the KERNEL_DTB macro to the INIT_DATA macro in
vmlinux.lds.h. This picks up the largest number of architectures that use
vmlinux.lds.h. INIT_DATA gets picked up by
#define INIT_DATA_SECTION(initsetup_align) \
.init.data : AT(ADDR(.init.data) - LOAD_OFFSET) { \
INIT_DATA \
INIT_SETUP(initsetup_align) \
INIT_CALLS \
CON_INITCALL \
SECURITY_INITCALL \
INIT_RAM_FS \
}
We could go into the INIT_TEXT macro to get the blobs into a RO section but that
seems kind of wrong.
IMHO if someone starts modifying things in .init.data and expect the changes to
stick they deserve what they get.
Comments/Suggestions?
--Dirk
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
