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 20:33:18 -0400 |
| |
On Sep 10, 2005, at 18:04:46, Andrew Morton wrote: > Kyle Moffett <mrmacman_g4@mac.com> wrote: >> When I started trying to split out the userspace<=>kernelspace ABI >> headers, I found a number of things (such as __ASSEMBLY__) that >> would not operate properly in userspace. > > Oh, OK.
[questions reordered to fit the answers better :-D]
> What's the status of this userspace ABI project? How far along is it?
It's just getting started. This is patch #1 :-D Unfortunately, this project will basically touch most or all of the header files, because anything that userspace wants to use (IOCTLs, structs, etc) needs to be put into a separate directory tree. We've kind of tentatively assigned "kabi" and "kcore" to that, but it's still really preliminary.
> Is it a thing we want to do?
The UML people really want this, because it would mean that UML could completely ignore libc for most of its code and just use the ABI and kcore headers. Since these headers would have a specially defined private namespace, they would be trivially useable from various libc implementations as well. (IE: everything begins with __kabi_ or __kcore_, except for macros which begin with __KABI_ or __KCORE_). The target for this is to also provide (in <kcore/*.h>) some optimized inline routines for user programs to use, some LGPL and others GPL. One example would be list.h, which I've copied and hacked on several times for various other GPL projects I've done work on.
> Have we worked out how it is to be done?
Here's what we've got so far:
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.
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 */
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. For example, the posix_types.h headers on most of the architectures have the same sizes for each type, only a few are different. With this we have a chance to have the few weird architectures do: #define __KABI_ARCH_TYPE_*_T __kabi_[su][0-9]+_t Then all the rest just use the default. This would make it much easier and less error-prone to add a new architecture, because you would have a really small set of structs, types, definitions, etc in <kabi/arch-*/*.h> that are _required_ across all architectures, and most of the stuff in asm-*/*.h would be header files for code that exists only on a _single_ architecture.
Cheers, Kyle Moffett
-- Unix was not designed to stop people from doing stupid things, because that would also stop them from doing clever things. -- Doug Gwyn
- 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/
| |