On 7/2/2010 12:11 PM, Arnd Bergmann wrote: > On Friday 02 July 2010, Chris Metcalf wrote: > >> So, if there's a good reason for it to be there, I'd say that pushes us >> back toward a separate <linux/list_types.h>. Otherwise we can >> investigate splitting out the prefetch content on every platform to >> <asm/prefetch.h> (presumably creating some empty <asm/prefetch.h> >> headers on architectures that just use the gcc builtin) and adding new >> #includes of <asm/prefetch.h> to files that reference the prefetch >> functionality. Arnd and other list folks, what's your instinct? >> > Makes sense. Splitting out the list types from list.h does seem to be > safest option. We might actually be able to do some header file > untangling that way, by using list_types.h in all headers that > use a list_head by none of the macros and functions associated with it. > For now I'll just stick with the straight splitting-out (see recent git email). There may be kernel code that is getting the list macros and functions "by accident" by including some header that in itself only needs the structs and so could use <linux/list_types.h>, and would need to #include <linux/list.h> itself to avoid breaking. There would probably be a long tail of complaints that developers' obscure architecture, driver, etc., had been broken by an aggressive "untangling" change. -- Chris Metcalf, Tilera Corp. http://www.tilera.com -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html