On Sun, 11 Mar 2007, Mike Frysinger wrote: > On 3/10/07, Rajat Jain <rajat.noida.india@xxxxxxxxx> wrote: > > On 3/11/07, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote: > > > is there, somewhere, a table of all of the gcc attributes used > > > commonly in the kernel? stuff like __devinitdata and so on. a > > > summary of stuff like that would be really handy. > > > > __devinitdata etc are not really gcc attributes, rather they are > > mostly just #defines to place the symbols in particular sections. > > i think he knows that ... the point was to get a list of all such > defines that the kernel has available precisely. i mean, beyond the beginner-level "coding style" guide, there seems to be no convenient summary of more *detailed* kernel programming guidelines. i once asked if there was a summary of the different printk debugging variations -- beyond printk, there's dev_dbg and DBG_printk and dev_printk and pr_debug and ... well, you get the idea. but there's no single explanation for where to use what for people who are getting started. i once submitted the following patch to the CodingStyle document to expand on how to use memory allocation primitives, but it was (justifiably) discouraged since it admittedly went beyond the bounds of mere coding style: + Chapter 18: Page-oriented memory management + +The following functions and macro definitions are available via +include/linux/gfp.h for page-oriented memory management: + + struct page *alloc_pages(gfp_mask, order); + unsigned long __get_free_pages(gfp_mask, order); + unsigned long get_zeroed_page(gfp_mask); + void __free_pages(struct page *page, order); + void free_pages(unsigned long addr, order); + + #define alloc_page(gfp_mask) alloc_pages(gfp_mask, 0) + #define __get_free_page(gfp_mask) __get_free_pages((gfp_mask),0) + #define __free_page(page) __free_pages((page), 0) + #define free_page(addr) free_pages((addr),0) + +Given the above, some basic suggestions for page-based memory management: + + (a) If you need to allocate or free a single page, use the single-page + version of the routine/macro, rather than calling the multi-page + version with an order value of zero, such as: + + alloc_pages(gfp_mask, 0); /* no */ + alloc_page(gfp_mask); /* better */ + + (b) If you need to allocate a single zeroed page by logical address, + use get_zeroed_page(), rather than __get_free_page() followed + by a call to memset() to clear that page. + + (Along these lines, don't call get_zeroed_page() and follow + that with a call to memset() to unnecessarily zero that page. + That's just being wasteful.) + + (c) If you need to clear (zero) a page, be aware that every + architecture defines a clear_page() routine, either as a macro + in include/<arch>/page.h or as an assembler routine. + + You should check if it's appropriate to use that routine/macro, + rather than making an explicit call to memset(...,0, PAGE_SIZE). + again, you get the idea. back a while, i created a separate page at the new KJ wiki: http://fsdev.net/wiki/index.php?title=Kernel_Programming_Guidelines just for programming guidelines. IMHO, it would be handy if interested people picked, say, a single topic and wrote a concise page on the recommended programming style for that topic. or something like that. thoughts? rday p.s. of course, there may already be writeups on some topics like that, so pointers to the available material would be good, too. -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page ======================================================================== -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
