T.R | Title | User | Personal Name | Date | Lines |
---|
764.1 | Re: Help adding a new kernel subsystem | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Thu Jun 02 1994 17:31 | 20 |
| Date Of Receipt: 27-MAY-1994 12:01:40.22
From: FLUME::jmcg "Jim McGinness"
To: [email protected]
CC: buildhelp@DEC:.zko.flume
Subj: Re: Help adding a new kernel subsystem
You didn't say you had done a
build BINARY
in this process. Your BINARY config file needs to contain the
options CCM
line, too. The BINARY_config step will update the BINARY Makefile
to contain references to your new subsystem and the BINARY_vmunix
step will build the object files.
-- jmcg
|
764.2 | Re: Help adding a new kernel subsystem | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Fri Jun 03 1994 13:18 | 115 |
| Date Of Receipt: 31-MAY-1994 09:53:13.09
From: WASTED::"[email protected]" "31-May-1994 0952"
To: [email protected]
CC:
Subj: Re: Help adding a new kernel subsystem
>
> You didn't say you had done a
>
> build BINARY
>
> in this process. Your BINARY config file needs to contain the
>
> options CCM
>
> line, too. The BINARY_config step will update the BINARY Makefile
> to contain references to your new subsystem and the BINARY_vmunix
> step will build the object files.
>
> -- jmcg
Ok, this helped somewhat (thanx), at least now my ccm subsystem tried to
build.
I've added a new /usr/include/cluster directory, I've added the appropriate
Makefile in the usr/include tree and done the build. The make/build works for
the cluster directory, it gets placed in the exports/include directory and the
exported ccm_def.h file that I specified goes along with it.
Unfortunately, the ccm kernel subsystem build doesn't seem to find the above
exports/cluster directory (I reference <cluster/ccm_def.h> from my source).
Q1: Where are the -I flags set/controlled from?
Q2: What is the magic build line to build *just* the ccm subsystem?
I've tried:
build BINARY_ccm # ng, takes forever
build BINARY_MAKE_ARGS="ccm.o" # ng, builds the world
build BINARY_vmunix # same thing, takes way too long
(About 10-15 minutes!, sometimes
when it goes and does a
for i in makedeptmp?? ... it takes
an hour or so)
Here is the tail end of a build BINARY_MAKE_ARGS="ccm.o" command:
about 200 lines of *stuff* removed
...
Kernel libraries are not used in alpha.
cd BINARY && make -cF
KCC=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/cc
LD=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ld
CPP=cpp AWK=awk
AR=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ar
RANLIB='/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ar
ts' SHELL=sh SED=sed SORT=sort ECHO=echo KSH=ksh EGREP=egrep
GREP=grep LINT=lint CONFIG=BINARY vmunix
/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/cc -c -O2
-g3 -DLANGUAGE_C -g3 -G 4 -I -I. -I.. -I../include -DIDENT=BINARY
-DDEC2100_A500 -DDEC2100_A50 -DLCAMUSTANG -DDEC2000_300 -DDEC3000_300
-DDEC3000_500 -DDEC7000 -DDEC4000 -DSWAPTYPE=1 -DRELEASE='"'9.0'"'
-DVERSION='"'0'"' -DMACH -DOSF -DCOMPAT_43 -DUFS -DTRN -DKERNEL
-D_KERNEL -D_BSD -signed -no_excpt -Wb,-static -Wco,-nofloat -Olimit
1500 -D__alpha -Umips -UMIPS -DBINARY ../ccm/ccm.c
/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/usr/lib/cmplrs/cc/cfe
:
Error: ../ccm/ccm.c: 2: Cannot open file cluster/ccm_def.h for #include
/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/usr/lib/cmplrs/cc/cfe
:
Error: ../ccm/ccm_internal_def.h: 4: Cannot open file cluster/ccm_def.h
for #include
*** Exit 1
Stop.
I don't see where the -I for /usr/sandboxes/clusters/export/alpha/usr/include
gets generated, which would pick up the cluster/ccm_def.h file.
I also don't understand why SOURCES get copied into my obj tree and then
don't get updated, for example, ccm.c got copied over there then I made
changes in the src tree and they weren't updated (why do we copy sources around
anyway?)
Is there a step by step bullet list somewhere that say's how the build process
works and what the dependencies are? I'd really feel better knowing:
1) Where to put my sources
2) Where to put my headers
3) Where to put my external headers (consumed by user level or other subsystems)
4) What targets are available in the build and what they accomplish.
5) Where compile flags are kept (both for local only changes and global)
6) The procedure for creating a new exported header (/usr/include/*)
7) The procedure for creating a new kernel subsystem.
8) The procedure for creating a new user level library.
9) The procedure for creating a new user level command.
10) What do people use to navigate the kernel code since tags files
aren't generated?
Sorry if this too many questions, but I don't have any documentation on this
build environment (other then the ODE slides) and I'm finding it hard to
get going.
Thanx.
-FredC
--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/\/\/\/\/\/\
< Fred Cassirer [email protected] >
< Digital Equipment Corporation Manalapan, NJ >
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
|
764.3 | Re: Help adding a new kernel subsystem | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Fri Jun 03 1994 13:19 | 12 |
| Date Of Receipt: 31-MAY-1994 10:00:57.85
From: FLUME::jmcg "Jim McGinness"
To: [email protected]
CC: buildhelp@DEC:.zko.flume
Subj: Re: Help adding a new kernel subsystem
You're asking too much from *this* buildhelp volunteer, at least for
right now, but I'll try to get back to you if I don't see an answer go
by on the buildhelp alias.
-- jmcg
|
764.4 | Re: Help adding a new kernel subsystem | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Fri Jun 03 1994 13:20 | 130 |
| Date Of Receipt: 31-MAY-1994 10:04:55.90
From: FLUME::"[email protected]" "Grant Van Dyck 31-May-1994 1003"
To: [email protected]
CC: [email protected]
Subj: Re: Help adding a new kernel subsystem
It would be a mistake to have the kernel build dependant
on include files in export. You may need to have the usr/include
build put them there for other reasons, utilites dependant on them,
user avalability etc, but not for the kernel build itself. If the build
needs them they should be in obj/alpha/kernel/include. You can't assume
that any developer or an build process will go build usr/include BEFORE
each and every kernel build (if at all).
As for the build line, instead of
build BINARY_MAKE_ARGS="ccm.o"
try
build BINARY_ MAKE_ARGS="ccm.o"
This is assuming of course that any other dependancies are built and in place.
-Grant
| Ok, this helped somewhat (thanx), at least now my ccm subsystem tried to
| build.
|
| I've added a new /usr/include/cluster directory, I've added the appropriate
| Makefile in the usr/include tree and done the build. The make/build works fo
r
| the cluster directory, it gets placed in the exports/include directory and th
e
| exported ccm_def.h file that I specified goes along with it.
|
| Unfortunately, the ccm kernel subsystem build doesn't seem to find the above
| exports/cluster directory (I reference <cluster/ccm_def.h> from my source).
|
| Q1: Where are the -I flags set/controlled from?
|
| Q2: What is the magic build line to build *just* the ccm subsystem?
| I've tried:
|
| build BINARY_ccm # ng, takes forever
| build BINARY_MAKE_ARGS="ccm.o" # ng, builds the world
| build BINARY_vmunix # same thing, takes way too lon
g
| (About 10-15 minutes!, sometimes
| when it goes and does a
| for i in makedeptmp?? ... it takes
| an hour or so)
|
|
| Here is the tail end of a build BINARY_MAKE_ARGS="ccm.o" command:
|
| about 200 lines of *stuff* removed
| ...
| Kernel libraries are not used in alpha.
| cd BINARY && make -cF
| KCC=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/cc
| LD=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ld
| CPP=cpp AWK=awk
| AR=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ar
| RANLIB='/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ar
| ts' SHELL=sh SED=sed SORT=sort ECHO=echo KSH=ksh EGREP=egrep
| GREP=grep LINT=lint CONFIG=BINARY vmunix
| /usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/cc -c -O2
| -g3 -DLANGUAGE_C -g3 -G 4 -I -I. -I.. -I../include -DIDENT=BINARY
| -DDEC2100_A500 -DDEC2100_A50 -DLCAMUSTANG -DDEC2000_300 -DDEC3000_300
| -DDEC3000_500 -DDEC7000 -DDEC4000 -DSWAPTYPE=1 -DRELEASE='"'9.0'"'
| -DVERSION='"'0'"' -DMACH -DOSF -DCOMPAT_43 -DUFS -DTRN -DKERNEL
| -D_KERNEL -D_BSD -signed -no_excpt -Wb,-static -Wco,-nofloat -Olimit
| 1500 -D__alpha -Umips -UMIPS -DBINARY ../ccm/ccm.c
| /usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/usr/lib/cmplrs/cc/
cfe
| :
| Error: ../ccm/ccm.c: 2: Cannot open file cluster/ccm_def.h for #include
| /usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/usr/lib/cmplrs/cc/
cfe
| :
| Error: ../ccm/ccm_internal_def.h: 4: Cannot open file cluster/ccm_def.h
| for #include
| *** Exit 1
| Stop.
|
|
| I don't see where the -I for /usr/sandboxes/clusters/export/alpha/usr/include
| gets generated, which would pick up the cluster/ccm_def.h file.
|
| I also don't understand why SOURCES get copied into my obj tree and then
| don't get updated, for example, ccm.c got copied over there then I made
| changes in the src tree and they weren't updated (why do we copy sources arou
nd
| anyway?)
|
| Is there a step by step bullet list somewhere that say's how the build proces
s
| works and what the dependencies are? I'd really feel better knowing:
|
| 1) Where to put my sources
| 2) Where to put my headers
| 3) Where to put my external headers (consumed by user level or other subsyste
ms)
| 4) What targets are available in the build and what they accomplish.
| 5) Where compile flags are kept (both for local only changes and global)
| 6) The procedure for creating a new exported header (/usr/include/*)
| 7) The procedure for creating a new kernel subsystem.
| 8) The procedure for creating a new user level library.
| 9) The procedure for creating a new user level command.
| 10) What do people use to navigate the kernel code since tags files
| aren't generated?
|
| Sorry if this too many questions, but I don't have any documentation on this
| build environment (other then the ODE slides) and I'm finding it hard to
| get going.
|
|
| Thanx.
| -FredC
|
| --
| /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/\/\/\/\/\/\
| < Fred Cassirer [email protected] >
| < Digital Equipment Corporation Manalapan, NJ >
| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
|
|
764.5 | Re: Help adding a new kernel subsystem | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Fri Jun 03 1994 14:37 | 32 |
| Date Of Receipt: 31-MAY-1994 23:14:31.60
From: FLAMBE::"[email protected]" "Shashi Mangalat USG 31-May-1994 2313"
To: [email protected], [email protected]
CC:
Subj: Re: Help adding a new kernel subsystem
As far as I know there is quick way to build just a subsystem. The
following steps might help in building the .o's you need.
# Copy header files and other data files over to the obj area.
# Configure *all* the various configurations. Your ccm option header
# files will created in this step.
#
% build setup
# build all .o's listed in MAKE_ARGS for the BINARY configuration
# The -k will continue build even if one of the objects failed to compile.
#
% build MAKE_ARGS="-k x.o y.o ..." BINARY_
# build all .o's listed in MAKE_ARGS for the FLAMINGO configuration
#
% build MAKE_ARGS="-k a.o b.o ..." FLAMINGO_
Note that you need to know which files gets built in BINARY .vs. any
other configuration. Trying to build a BINARY file in COBRA will just
generate a symlink.
Hope this helps and let me know if you still have problems building.
--shashi
|
764.6 | Re: Help adding a new kernel subsystem | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Fri Jun 03 1994 14:40 | 165 |
| Date Of Receipt: 1-JUN-1994 08:29:37.28
From: WASTED::"[email protected]" "01-Jun-1994 0823"
To: [email protected]
CC: Grant Van Dyck <[email protected]>
Subj: Re: Help adding a new kernel subsystem
Thanx for the replies! Some addition comments/questions follow:
>
> It would be a mistake to have the kernel build dependant
> on include files in export. You may need to have the usr/include
> build put them there for other reasons, utilites dependant on them,
> user avalability etc, but not for the kernel build itself.
Understood, I wasn't *trying* to cause this, I just don't have a clue
as to how this build process works and where the build is getting things
from etc, again, aren't there any docs you can point me at?
> If the build
> needs them they should be in obj/alpha/kernel/include. You can't assume
> that any developer or an build process will go build usr/include BEFORE
> each and every kernel build (if at all).
>
Do *I* need to manually put things in obj/alpha/kernel/include? Isn't this
a temp directory where the output of the build goes? Where do I put my
kernel only headers (non-exported) so that they can be found by the build?
> As for the build line, instead of
>
> build BINARY_MAKE_ARGS="ccm.o"
> try
> build BINARY_ MAKE_ARGS="ccm.o"
>
>
> This is assuming of course that any other dependancies are built and in place
.
Ok, this worked, only took a few minutes. The depencencies aren't a problem,
they have been identified by the setup already, and unless I change them doing
the single object builds should be ok.
Thanx!
>
>
> -Grant
>
>
>
> | Ok, this helped somewhat (thanx), at least now my ccm subsystem tried to
> | build.
> |
> | I've added a new /usr/include/cluster directory, I've added the appropriate
> | Makefile in the usr/include tree and done the build. The make/build works
fo
> r
> | the cluster directory, it gets placed in the exports/include directory and
th
> e
> | exported ccm_def.h file that I specified goes along with it.
> |
> | Unfortunately, the ccm kernel subsystem build doesn't seem to find the abov
e
> | exports/cluster directory (I reference <cluster/ccm_def.h> from my source).
> |
> | Q1: Where are the -I flags set/controlled from?
> |
> | Q2: What is the magic build line to build *just* the ccm subsystem?
> | I've tried:
> |
> | build BINARY_ccm # ng, takes forever
> | build BINARY_MAKE_ARGS="ccm.o" # ng, builds the world
> | build BINARY_vmunix # same thing, takes way too lon
> g
> | (About 10-15 minutes!, someti
mes
> | when it goes and does a
> | for i in makedeptmp?? ... it takes
> | an hour or so)
> |
> |
> | Here is the tail end of a build BINARY_MAKE_ARGS="ccm.o" command:
> |
> | about 200 lines of *stuff* removed
> | ...
> | Kernel libraries are not used in alpha.
> | cd BINARY && make -cF
> | KCC=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/cc
> | LD=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ld
> | CPP=cpp AWK=awk
> | AR=/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ar
> | RANLIB='/usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/ar
> | ts' SHELL=sh SED=sed SORT=sort ECHO=echo KSH=ksh EGREP=egrep
> | GREP=grep LINT=lint CONFIG=BINARY vmunix
> | /usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/cc -c -O2
> | -g3 -DLANGUAGE_C -g3 -G 4 -I -I. -I.. -I../include -DIDENT=BINARY
> | -DDEC2100_A500 -DDEC2100_A50 -DLCAMUSTANG -DDEC2000_300 -DDEC3000_300
> | -DDEC3000_500 -DDEC7000 -DDEC4000 -DSWAPTYPE=1 -DRELEASE='"'9.0'"'
> | -DVERSION='"'0'"' -DMACH -DOSF -DCOMPAT_43 -DUFS -DTRN -DKERNEL
> | -D_KERNEL -D_BSD -signed -no_excpt -Wb,-static -Wco,-nofloat -Olimit
> | 1500 -D__alpha -Umips -UMIPS -DBINARY ../ccm/ccm.c
> | /usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/usr/lib/cmplrs/c
c/
> cfe
> | :
> | Error: ../ccm/ccm.c: 2: Cannot open file cluster/ccm_def.h for #include
> | /usr/sde/osf1/build/goldos.bl10/tools/alpha_OSF1/alpha/acc/usr/lib/cmplrs/c
c/
> cfe
> | :
> | Error: ../ccm/ccm_internal_def.h: 4: Cannot open file cluster/ccm_def.h
> | for #include
> | *** Exit 1
> | Stop.
> |
> |
> | I don't see where the -I for /usr/sandboxes/clusters/export/alpha/usr/inclu
de
> | gets generated, which would pick up the cluster/ccm_def.h file.
> |
> | I also don't understand why SOURCES get copied into my obj tree and then
> | don't get updated, for example, ccm.c got copied over there then I made
> | changes in the src tree and they weren't updated (why do we copy sources ar
ou
> nd
> | anyway?)
> |
> | Is there a step by step bullet list somewhere that say's how the build proc
es
> s
> | works and what the dependencies are? I'd really feel better knowing:
> |
> | 1) Where to put my sources
> | 2) Where to put my headers
> | 3) Where to put my external headers (consumed by user level or other subsys
te
> ms)
> | 4) What targets are available in the build and what they accomplish.
> | 5) Where compile flags are kept (both for local only changes and global)
> | 6) The procedure for creating a new exported header (/usr/include/*)
> | 7) The procedure for creating a new kernel subsystem.
> | 8) The procedure for creating a new user level library.
> | 9) The procedure for creating a new user level command.
> | 10) What do people use to navigate the kernel code since tags files
> | aren't generated?
> |
> | Sorry if this too many questions, but I don't have any documentation on thi
s
> | build environment (other then the ODE slides) and I'm finding it hard to
> | get going.
> |
> |
> | Thanx.
> | -FredC
> |
> | --
> | /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/\/\/\/\/\/\
> | < Fred Cassirer [email protected] >
> | < Digital Equipment Corporation Manalapan, NJ >
> | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
> |
|
764.7 | Re: Help adding a new kernel subsystem | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Fri Jun 03 1994 14:42 | 38 |
| Date Of Receipt: 1-JUN-1994 08:42:43.94
From: FLUME::"[email protected]" "Grant Van Dyck 01-Jun-1994 0840"
To: [email protected]
CC: [email protected]
Subj: Re: Help adding a new kernel subsystem
| > It would be a mistake to have the kernel build dependant
| > on include files in export. You may need to have the usr/include
| > build put them there for other reasons, utilites dependant on them,
| > user avalability etc, but not for the kernel build itself.
|
| Understood, I wasn't *trying* to cause this, I just don't have a clue
| as to how this build process works and where the build is getting things
| from etc, again, aren't there any docs you can point me at?
Not really, not that there shouldn't be, there just isn't any that I know of.
|
| > If the build
| > needs them they should be in obj/alpha/kernel/include. You can't assume
| > that any developer or an build process will go build usr/include BEFORE
| > each and every kernel build (if at all).
| >
|
| Do *I* need to manually put things in obj/alpha/kernel/include? Isn't this
| a temp directory where the output of the build goes? Where do I put my
| kernel only headers (non-exported) so that they can be found by the build?
Yes, but build setup should do a lot of that. I wouldn't call it a temp
directory, the build looks in here to find what it needs. The include files
that get shipped come from obj/alpha/usr/include/ subdirs and if a kernel
include file needs to be shipped, the appropriate Makefile rules need to
be in place in the usr/include space to reach into the kernel space and get
what it needs.
-Grant
|
764.8 | Re: Help adding a new kernel subsystem | SMURF::FILTER | Automatic Posting Software - mail to flume::puck | Fri Jun 03 1994 14:43 | 68 |
| Date Of Receipt: 1-JUN-1994 09:19:01.60
From: WASTED::dupuis "Gary Dupuis New CPU Support 01-Jun-1994 0915"
To: [email protected]
CC: buildhelp@DEC:.zko.wasted, dupuis@DEC:.zko.wasted
Subj: Re: Help adding a new kernel subsystem
The correct way to have move kernel include files to the
obl/alpha/kernel/include area is to create an entry for them in
the appropriate Makefile down the ...src/kernel/include branch.
For examples look at
../src/kernel/include/arch/alpha/hal/Makefile.
Gary
=======================================
Return-Path: vandyck
Received: from cardinal.zk3.dec.com by wasted.zk3.dec.com;
(5.65/1.1.8.2/26May94-1021AM)
id AA11622; Wed, 1 Jun 1994 08:42:19 -0400
Received: by cardinal.zk3.dec.com; id AA01018; Wed, 1 Jun 1994 08:40:04 -0400
Message-Id: <[email protected]>
To: [email protected]
Cc: buildhelp
Subject: Re: Help adding a new kernel subsystem
In-Reply-To: Your message of "Wed, 01 Jun 94 08:23:38 EDT."
<[email protected]>
Date: Wed, 01 Jun 94 08:40:04 -0400
From: Grant Van Dyck <vandyck>
X-Mts: smtp
| > It would be a mistake to have the kernel build dependant
| > on include files in export. You may need to have the usr/include
| > build put them there for other reasons, utilites dependant on them,
| > user avalability etc, but not for the kernel build itself.
|
| Understood, I wasn't *trying* to cause this, I just don't have a clue
| as to how this build process works and where the build is getting things
| from etc, again, aren't there any docs you can point me at?
Not really, not that there shouldn't be, there just isn't any that I know of.
|
| > If the build
| > needs them they should be in obj/alpha/kernel/include. You can't assume
| > that any developer or an build process will go build usr/include BEFORE
| > each and every kernel build (if at all).
| >
|
| Do *I* need to manually put things in obj/alpha/kernel/include? Isn't this
| a temp directory where the output of the build goes? Where do I put my
| kernel only headers (non-exported) so that they can be found by the build?
Yes, but build setup should do a lot of that. I wouldn't call it a temp
directory, the build looks in here to find what it needs. The include files
that get shipped come from obj/alpha/usr/include/ subdirs and if a kernel
include file needs to be shipped, the appropriate Makefile rules need to
be in place in the usr/include space to reach into the kernel space and get
what it needs.
-Grant
|