From: Jon Smirl <jonsmirl@ya...> - 2003-02-02 02:24:39
I'm beginning to have second thoughts about having an
arch directory below include/asm. A lot of the h files
in include/asm include their counter part in
include/arch/asm. I was following this practice with
io.h and pci.h.
I'm now starting to think that we should get rid of
include/asm/arch. For several reasons:
1) UML is it's own architecture. In most cases it is
not just a simple twist on the underlying
architecture. UML's architecture is the userspace API
2) The files in include/arch/asm contain a lot of
inline functions. I have been bitten several times by
this. The functions compile ok and then silently fail
when run from userspace. I have to find these one by
one and override them with code that works under UML.
3) The files in include/arch/asm define a lot of stuff
that isn't present in UML. For example the X86 files
define a lot of stuff for the ISA and EISA bus. This
will allow ISA and EISA drivers to build under UML but
they aren't going to work. They are probably going to
silently fail. By making UML spec versions of these
files we can leave out the ISA stuff and the drivers
won't even compile.
4) Many of the things defined in the platform specific
h files should be mapped to C runtime calls. For
example udelay(), having it call nanosleep() works on
all platforms. This is a better solution that trying
to make each platform's version of udelay() work
The user space Linux API is portable across all
implementations of Linux. Shouldn't we be working to
remove all dependences on platform specific files from UML?
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.