Bug #378
closedunbreak individual module building
0%
Description
Following patch unbreaks module building without quickkernel or buildkernel:
http://leaf.dragonflybsd.org/~sephe/cpu_machine1.diff
Please review it
Best Regards,
sephe
Updated by dillon about 18 years ago
:
: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>
Updated by dillon about 18 years ago
: 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>
Updated by justin about 18 years ago
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.
Updated by sepherosa about 18 years ago
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
Updated by dillon about 18 years ago
: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
Updated by dillon about 18 years ago
:
: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>
Updated by corecode about 18 years ago
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
Updated by sepherosa about 18 years ago
Yeah, it will not affect buildkernel stuffs :-)
Best Regards,
sephe
Updated by sepherosa about 18 years ago
Ok, I will change it once I get home.
Cheers,
sephe
Updated by sepherosa about 18 years ago
Please review it:
http://leaf.dragonflybsd.org/~sephe/config3.diff
If no objection, I will commit it on this Friday.
Best Regards,
sephe
Updated by corecode about 18 years ago
Looks good, but I think the @'s are not neccessary. no problems telling the user what is happening, no?
cheers
simon
Updated by qhwt+dfly about 18 years ago
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.
Updated by dillon about 18 years ago
:> 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>
Updated by sepherosa about 18 years ago
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