To: None <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 07/22/2000 17:56:06
firstname.lastname@example.org (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>
> #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
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.