Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: [RFC][MEGAPATCH] Change __ASSEMBLY__ to __ASSEMBLER__ (defined by GCC from 2.95 to current CVS) | Date | Sat, 10 Sep 2005 23:15:44 -0400 |
| |
On Sep 10, 2005, at 20:48:18, Andrew Morton wrote: >> 1) At some point the arch/driver/etc maintainers (for anything that >> interacts with userspace), need to start converting things on their >> own (such as moving ioctl and struct declarations to a <kabi/*.h> >> header file), because the people working on it certainly don't have >> all the varieties of hardware and userspace programs that would be >> affected by this change. > > This will be very disruptive.
I know, but currently it places a lot of unnecessary load on the linux-libc-headers maintainer, and sometimes that doesn't get done correctly. For most of the above, all the maintainer will need to do is move the ioctl and struct declarations necessary in userspace from the header file in linux/ to a corresponding one in kabi/, _maybe_ change a few macro names, and then verify that it all still works correctly.
>> 2) The goal is to minimize changes to kernel code. I'm not out to >> rename "struct list_head", that would be silly! Instead, the header >> <linux/list.h> would be basically reduced to this: >> >> #ifndef __LINUX_LIST_H >> # define __LINUX_LIST_H 1 >> # ifdef __KERNEL__ >> >> # define __kcore_list_item list_head >> # include <kcore/list.h> >> # define list_add(x,y) __kcore_list_add(x,y) >> >> [...etc...] >> >> # endif /* __KERNEL__ */ >> #endif /* not __LINUX_LIST_H */ > > I hope list.h was a poorly-chosen example, and that there are no > plans to > actually do anything like the above to list.h.
Yeah, that was actually a rather poorly chosen example, but it does somewhat illustrate the way we would preserve compatibility.
> Surely the only files which need to be altered are those which we can > reasonably expect userspace to actually include.
Yeah. I would have given one of the types.h files, except those are so massively chaotic and with all sorts of cross dependencies that I haven't tinkered with them enough yet. I'm working on it, though!
>> 3) Another side effect of this project will be that we will have >> the chance to clean up and merge some of the stuff currently in >> the asm-* directories. > > I'd suggest that you avoid side-effects. Unrelated cleanups are > unrelated > - do it as a separate project.
My plan is to start with a bunch of cleanups that make it easier to split the files, and then proceed to begin splitting the low level files that are essential to everything else. Once that's done, I would move on to the other headers, the ones that have dependencies on lots of headers. I'll probably have to submit cleanups to stuff like linux/kernel.h, linux/sched.h, etc, to prevent include cycles.
> I'm very dubious about the whole idea, frankly.
This would make life a million times easier for the UML people, the glibc people, the klibc people, and the linux-libc-headers maintainer (IE: you don't need one, and he can go do something more productive), etc. If you want proof, several of the above groups have previously voiced in support of this project in this very thread.
This is definitely not a short-term project, and will really only reach significant improvements for those groups by around 2.6.30 or so, but many feel it's a necessary change.
Cheers, Kyle Moffett
-- I lost interest in "blade servers" when I found they didn't throw knives at people who weren't supposed to be in your machine room. -- Anthony de Boer
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |