DragonFlyBSD

:
:Following patch unbreaks module building without quickkernel or buildkernel:
:http://leaf.dragonflybsd.org/~sephe/cpu_machine1.diff
:
:Please review it
:
:Best Regards,
:sephe
:
:--
:Live Free or Die

No, all files outside of the machine headers MUST include <machine/*.h>,
     NEVER <cpu/*.h>.

We will either have to make stand-alone module builds use the 
     system header files in /usr/include, or we will have to construct
     a proper machine/ and cpu/ infrastructure for them just like the kernel
     and world build does.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

: No, all files outside of the machine headers MUST include <machine/*.h>,
: NEVER <cpu/*.h>.

I should explain this a bit more.  What is happening here is that
   there are platform architecture specific includes <machine/*.h> and
   there are cpu architecture specific includes <cpu/*.h>

BUT all #include lines must go via <machine/*.h> in order to give the
   platform architecture a chance to override or enhance/add-to the 
   cpu architecture.

This means that a header file must exist in <machine/*.h> for every
   header in <cpu/*.h>.  I did not want to create a mess of forwarding-only
   header files in the platform architectures - amoung other things this
   would make it difficult to impossible to keep everything synchronized
   when adding or removing cpu architecture headers, since (potentially)
   many platforms might reference the same cpu architecture.  Also, certain
   platforms such as VKERNEL might wind up referencing any number of
   different cpu architectures depending on 'machine_arch' directive in
   the kernel config file.

Because of all this the buildworld (in src/include/Makefile*) and
   buildkernel (in src/Makefile.inc1) targets synthesize the 'missing'
   <machine/*.h> header files by either creating a forwarding header
   file to <cpu/*.h> or simply copying the <cpu/*.h> to the machine/
   sub directory in the object tree or in /usr/include.

This allows us to omit pure forwarding header files.  It also means 
   that ALL sources must access platform or cpu architecture headers
   via <machine/*.h> or risk becoming a porting nightmare when we expand
   to other cpu architectures.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

On Sun, November 12, 2006 2:38 pm, Matthew Dillon wrote:

After this file shuffle, is it going to be worthwhile to port to other
architectures? It'd be nice, especially since pkgsrc is already
cross-platform.

Sorry, I didn't read the commit log carefully enough :-P. Thanks for
the explaination.

I prefer to synthesizing missing headers:
http://leaf.dragonflybsd.org/~sephe/config2.diff

Please review it.

Best Regards,
sephe

:Sorry, I didn't read the commit log carefully enough :-P. Thanks for
:the explaination.
:
:> Because of all this the buildworld (in src/include/Makefile*) and
:> buildkernel (in src/Makefile.inc1) targets synthesize the 'missing'
:> <machine/*.h> header files by either creating a forwarding header
:> file to <cpu/*.h> or simply copying the <cpu/*.h> to the machine/
:> sub directory in the object tree or in /usr/include.
:
:I prefer to synthesizing missing headers:
:http://leaf.dragonflybsd.org/~sephe/config2.diff
:
:Please review it.
:
:Best Regards,
:sephe

This will generate a copy for each module, but I think that might be ok
    since modules are not usually built without a kernel context.  I presume
    that the only time this mechanism is used is when you build a module
    manually, right?

-Matt

:
:On Sun, November 12, 2006 2:38 pm, Matthew Dillon wrote:
:
:> This allows us to omit pure forwarding header files. It also means
:> that ALL sources must access platform or cpu architecture headers
:> via <machine/*.h> or risk becoming a porting nightmare when we expand
:> to other cpu architectures.
:
:After this file shuffle, is it going to be worthwhile to port to other
:architectures? It'd be nice, especially since pkgsrc is already
:cross-platform.

The work is primarily to support the virtual kernel build, but I have
    an eye towards other architectures at the same time.

I would say only about 30% of the cleanup is done.  There are still a
    large number of mechanisms that are in the platform architecture tree
    that should either be in the cpu architecture tree or should be in
    machine-independant files.  I am cleaning things up as I go.

VKERNEL now compiles and links against libc, but of course there are
    many missing symbols.  I still have a huge amount of work to do.
    Kernel support for virtual kernel operations is almost done.   The
    hard part... the 'MMU' emulation works.  Context switching works.
    Traps and exceptions still need work.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

possibly a nitpick, but: won't that break when you ^C config while creating the forwarding headers? maybe the target should be something like ${_MACHINE_INC}/.done, which gets touch'ed after running config?

cheers
simon

Yeah, it will not affect buildkernel stuffs :-)

Best Regards,
sephe

Ok, I will change it once I get home.

Cheers,
sephe

Please review it:
http://leaf.dragonflybsd.org/~sephe/config3.diff

If no objection, I will commit it on this Friday.

Best Regards,
sephe

Looks good, but I think the @'s are not neccessary. no problems telling the user what is happening, no?

cheers
simon

Hi, just a bikeshed now that you have an already working patch :), but
the generate_forwarding_headers() can be implemented as kernel make rules:

http://les.ath.cx/DragonFly/fwd_hdr.diff.gz

Cheers.

:> Please review it:
:> http://leaf.dragonflybsd.org/~sephe/config3.diff
:>
:> If no objection, I will commit it on this Friday.
:
:Hi, just a bikeshed now that you have an already working patch :), but
:the generate_forwarding_headers() can be implemented as kernel make rules:
:
: http://les.ath.cx/DragonFly/fwd_hdr.diff.gz
:
:Cheers.

I'll leave it up to Sephe.  Either way works for me.

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

I think it is better and cleaner than generating headers in config(8),
I have adjusted YONETANI's version a little bit, mainly in kmod.mk
1) use forwarder_${MACHINE_ARCH} instead of forwarder_i386
2) if MAKEOBJDIRPREFIX is not set, ${.OBJDIR}/forward_${MACHINE_ARCH}
is used, or forward_${MACHINE_ARCH} will be created in /usr/src/sys,
that's probably not what we want
3) nuke generate_forwarding_headers() in usr.sbin/config/main.c

Please review it:
http://leaf.dragonflybsd.org/~sephe/fwd_hdr1.diff

Best Regards,
sephe

committed:
http://leaf.dragonflybsd.org/mailarchive/commits/2006-11/msg00113.html