Re: [RFC][MEGAPATCH] Change __ASSEMBLY__ to __ASSEMBLER__ (defined by GCC from 2.95 to current CVS)

[Kyle Moffett <mrmacman_g4@mac.com>]

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/