thorpej@zembu.com (Jason R Thorpe) writes:
> On Sat, Jul 22, 2000 at 12:44:40PM -0700, Matt Thomas wrote:
>  > I'd like to propose that the definition and use of
>  > <machine/foo.h> be changed/modified.  Currently
>  > machine points to the port specific include directory
>  > and then there's a <$arch$/foo.h> which points to the
>  > machine archtecture files.

[ note that i've been advocating going in this direction for a couple
of years, though not loudly. ]


> The problem, of course, is kernel source files that do, e.g.:
> 
> #include <machine/bus.h>
> 
> Those are port-specific, not arch-specific.

That may depend on how you look at it.

for instance, is a 'random generic kernel loadable module' (if one
exists 8-) supposed to work on a given MACHINE, or MACHINE_ARCH, and
if the former, why?  similar question for drivers: if it's a PCI
device, why should it care?  (an LKM interface for the bus functions
should expose fn calls, anyway, rather than complex macro hair.)


> I think what we really want is:
> 
> #include <arch/foo.h>
> 
> and
> 
> #include <machine/foo.h>
> 
> Userland sources should be changed to use <arch/foo.h>, kernel sources
> must still be able to do <machine/foo.h>.

I disagree.  Like, "forever" on BSD systems the notion of using
<machine/foo.h> has been accepted.  We have been encouraging its use
for N years now.

If you want to change it, the right thing to do is make the change
which impacts minimum user code: make user code include ports' headers
explicitly if they want them, but make 'machine' corresspond to the
portable bits for the architecture.


> The <machine/...> API should not be accessible from userland, i.e. the
> symlink in /usr/include should go away, in favor of the <arch/...> link.

except, it has been for N years, and how much source would need to be
changed to 'fix' it?  then further, how much of that change is
actually _necessary_?

if you basically just want to effectively, rename the directory used
by userland, better to keep the compatible name and provide the
correct, portable contents.


> Anyway, I think this is actually a complicated problem, and is going to
> require a lot of thought to fix.

that i believe.



cgd