[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3] ns16550-Add-command-line-parsing-adjustments
>>> On 17.04.17 at 17:51, <sparatey@xxxxxxx> wrote: > I have a question about __initconst that you mentioned. Sure, but please trim your replies. > On 4/3/2017 6:55 AM, Jan Beulich wrote: >>>>> On 31.03.17 at 17:42, <swapnil.paratey@xxxxxxx> wrote: >>> +/* enum struct keeping a table of all accepted parameter names >>> + * for parsing cmdline for serial port com1 and com2 */ >>> +static struct serial_param_var sp_vars[] = { >> const ... __initconst plus you should aim at arranging for the >> string literals below to also get placed in .init.rodata (instead of >> .rodata). > > Adding an __initconst before the variable name (or after it) makes > sp_vars go into the .init.data section if I check through > "objdump -t xen-syms | grep sp_vars" > > I'm not being able to see an init.rodata section at all for any > other variable to emulate similar behavior i.e. > doing an "objdump -t xen-syms | grep .init.rodata" > doesn't show any results (whereas .init.data shows many). > > The header file for __initconst defines it as .init.rodata but > sp_vars ends up in init.data > > I compile Xen by going into xen/xen and running make -j`nproc` > > Please let me know if I'm misunderstanding something. > What behavior I should expect and what is expected for adding > these string literals. Pointing to an example would be helpful. See the linker script: .init.rodata (and a few sub-flavors) get merged into .init.data. We don't _currently_ have a need to separate r/o from r/w init data, but source code should nevertheless correctly reflect const-ness. Hence you looking at xen-syms instead of ns16550.o is misleading you. As to examples - please simply grep for other uses of __initconst. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |