Bug #378

unbreak individual module building

Added by sepherosa over 7 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Following patch unbreaks module building without quickkernel or buildkernel:
http://leaf.dragonflybsd.org/~sephe/cpu_machine1.diff

Please review it

Best Regards,
sephe

History

#1 Updated by dillon over 7 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
<>

#2 Updated by dillon over 7 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
<>

#3 Updated by justin over 7 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.

#4 Updated by sepherosa over 7 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

#5 Updated by dillon over 7 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

#6 Updated by dillon over 7 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
<>

#7 Updated by corecode over 7 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

#8 Updated by sepherosa over 7 years ago

Yeah, it will not affect buildkernel stuffs :-)

Best Regards,
sephe

#9 Updated by sepherosa over 7 years ago

Ok, I will change it once I get home.

Cheers,
sephe

#10 Updated by sepherosa over 7 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

#11 Updated by corecode over 7 years ago

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

cheers
simon

#12 Updated by qhwt+dfly over 7 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.

#13 Updated by dillon over 7 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
<>

#14 Updated by sepherosa over 7 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

Also available in: Atom PDF