Thanks for the reply. Sorry I didn't find the __initdata attribute. Is this stuff worth patching? I'd make the following changes as a start: in arch/mips/mips-boards/generic/printf.c: Add __init to putPromChar Add __init to getPromChar Add __initdata to buf (1k buffer) in arch/mips/mips-boards/generic/cmdline.c: Add __initdata to arcs_cmdline Can someone point to a set of rules for submitting patches for linux-mips? I'm familiar with the methods used for the kernel. Is this the same? I'm using 2.4.3 from the mips site. Can I patch against that, or do I have to start from a certain cvs version? Thanks! Gerald Zhang Fuxin wrote: > hi,Gerald Champagne£¬ > I think __initdata attribute is the answer.You just need to > put init data in init data section(via __initdata),there are many examples > in kernel. > > > ÔÚ 2001-09-18 12:58:00 you wrote£º > >>I noticed that several global buffers are used by a few functions marked >>as __init functions. I assume that the code space used by these functions >>will be freed up when kernel initialization is completed, but can the >>associated global memory be freed up as well? >> >>An example can be found in arch/mips/mips-boards/generic/cmdline.c: >> >>char arcs_cmdline[COMMAND_LINE_SIZE]; >>char * __init prom_getcmdline(void); >>void __init prom_init_cmdline(void); >> >>arcs_cmdline is only used by these two functions and one other function >>marked as __init. >> >>This buffer is small, but it can apply to larger buffers as well. For >>example, in arch/mips/mips-boards/generic/printf.c, I think the functions >>putPromChar and getPromChar should be marked as __init functions, and the >>1k buffer "buf" is never used after initialization. Can this 1k be recovered? >> >>I know kmalloc could normally be used in kernel code, but that won't work on >>initialization code used before kmalloc is initialized. >> >>Thanks. >> >>Gerald >> > > Regards > Zhang Fuxin > fxzhang@ict.ac.cn > > > >
