Re: CVS commit: src/distrib/common
With tarballs the latest timestamp of them, with source tree I don't know. :) I'm only pointing out an interesting, reasonable idea, not asking you to implement it right now. On Wednesday, 25 November 2015, Christos Zoulas wrote: > In article < > cadbf7ee9mruyyct+97v1bjh_0nh9tqltr-rm5bprgl+knb2...@mail.gmail.com > >, > Masao Uebayashi > wrote: > >bapt@freebsd taught me that FreeBSD uses ((the newest timestamp in the > >source files) + 1sec) in places where appropriate for reproducible > >build. It might have been about Ports, but idea is it. > > That's a nice way to do it. How do they compute that? > > christos > >
Re: CVS commit: src/distrib/common
bapt@freebsd taught me that FreeBSD uses ((the newest timestamp in the source files) + 1sec) in places where appropriate for reproducible build. It might have been about Ports, but idea is it. On Wed, Nov 25, 2015 at 9:50 AM, Christos Zoulas wrote: > Module Name:src > Committed By: christos > Date: Wed Nov 25 00:50:57 UTC 2015 > > Modified Files: > src/distrib/common: Makefile.bootcd > src/distrib/common/bootimage: Makefile.bootimage > > Log Message: > PR/50360: Thomas Klausner: if MKREPRO is set, provide a consistent timestamp > for the files in the cdroms to be built. For now we copy the timestamp of > . We could set an absolute timestamp too like -T 0 for the epoch. > > > To generate a diff of this commit: > cvs rdiff -u -r1.32 -r1.33 src/distrib/common/Makefile.bootcd > cvs rdiff -u -r1.11 -r1.12 src/distrib/common/bootimage/Makefile.bootimage > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/share/mk
On Tue, Sep 8, 2015 at 1:33 AM, Joerg Sonnenberger
wrote:
> On Mon, Sep 07, 2015 at 06:42:07AM +0000, Masao Uebayashi wrote:
>> Module Name: src
>> Committed By: uebayasi
>> Date: Mon Sep 7 06:42:07 UTC 2015
>>
>> Modified Files:
>> src/share/mk: bsd.lib.mk
>>
>> Log Message:
>> Order object build alphabetically.
>
> Given that we are still tsorting things: this change is wrong.
Could you elaborate more? What I see is that, ${.ALLSRC:O} is
lorder(1)'ed, and then tsort(1)'ed.
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Sep 6, 2015 at 4:17 PM, Masao Uebayashi wrote:
> Module Name:src
> Committed By: uebayasi
> Date: Sun Sep 6 07:17:14 UTC 2015
>
> Modified Files:
> src/sys/arch/amd64/conf: Makefile.amd64 files.amd64
>
> Log Message:
> Define MD start code at the top of files.${MACHINE} relying on config(1)'s
> deterministic file output order. No need to define ${MD_OBJS} and its
> useless,
> explicit compile rules.
Although it was true that config(1) preserves file order, I have
mistakenly reordered files in ${OBJS}, that is passed to ${LD}, and
the first file (locore.o) has been mistakenly linked after all *.o
files derived from *.c. Just fixed now in sys/conf/Makefile.kern.inc
Rev. 1.244.
(Kernel booted because boot loader honored ELF entry address.)
Re: CVS commit: src/sys/arch/m68k/fpsp
On Mon, Sep 7, 2015 at 7:01 AM, David Laight wrote:
> On Sat, Sep 05, 2015 at 09:39:43AM +0900, Masao Uebayashi wrote:
>> The reason of this is that config(1) have no idea of library at this
>> moment. Makefile.kern.inc has also a convention that all *.o files
>> have to be built under the top of kernel build directory. libkern &
>> libcompat have speicalized make(1) rules, that work but look ugly.
>> I'd consider to extend config(1) to support library...
The first `this' referred to a rule I added to fix build:
fpsp.o: ${FPSP}
ln -sf ${FPSP} fpsp.o
where ${FPSP} is an absolute path to ${.OBJDIR}/lib/fpsp/fpsp.o.
m68k defined ${FPSP} as ${MD_OBJS}, but I changed paths in ${MD_OBJS}
to be normalized to just file names (no /) to simplify explicit rule
generation. Now that I introduced ${MD_LIBS}, whose paths are not
normalized, that symlink is no longer needed & removed.
(As a bonus, fpsp.o is linked at last, not just after start code.
Like other libraries.)
> Please can you keep some context in your emails.
> The 'this' is the first line is a reference to something unknown.
>
> Oh, and one historic reason for the kernel objects being in a .a
> file was to allow builds on systems with short command line length
> limits.
>
> David
>
> --
> David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/arch/m68k/fpsp
The reason of this is that config(1) have no idea of library at this moment. Makefile.kern.inc has also a convention that all *.o files have to be built under the top of kernel build directory. libkern & libcompat have speicalized make(1) rules, that work but look ugly. I'd consider to extend config(1) to support library...
Re: CVS commit: src
I will bring this back to track once things will settle.
Re: CVS commit: src/sys/conf
My plan is to order objects following module dependency for kernel constructors.
Re: CVS commit: src/usr.bin/config
On Fri, Sep 4, 2015 at 4:10 AM, matthew green wrote:
> Masao Uebayashi writes:
>> They were intentionally overly strict. Please put them back. Or
>> change them to not overly strict.
>
> there's no good reason to change either makeoptions to to force all options
> to be listed in the files files. like most of the items in config/TODO,
> there is no rationale why these changes should be made. i removed these
> two items because they are things people *want* to remain.
I reread this sentence 5 times and found zero technical reasoning.
>> You make me wonder if I should add this to Makefile.kern.nc:
>>
>> ${SYSTEM_OBJ}: Makefile
>
> this is ridiculous.
What happens if you change maxusers and rebuild your kernel?
Re: CVS commit: src/sys/conf
On Thu, Sep 3, 2015 at 11:32 PM, Joerg Sonnenberger
wrote:
> On Thu, Sep 03, 2015 at 02:56:35PM +0900, Masao Uebayashi wrote:
>> Because ${OBJS} affects not only build order but also link order.
>
> and that's exactly why it *should* be sorted. Please don't introduce
> sources of instability to the build process.
config(1) outputs ${CFILES}/${SFILES} in the order it parses files.*
and sees "file ...". It is stable.
Re: CVS commit: src/usr.bin/config
They were intentionally overly strict. Please put them back. Or
change them to not overly strict.
You make me wonder if I should add this to Makefile.kern.nc:
${SYSTEM_OBJ}: Makefile
Re: CVS commit: src/sys/conf
I got some errors from common/lib/libc/arch/arm/features.mk. Will revisit later.
Re: CVS commit: src/sys/conf
Because ${OBJS} affects not only build order but also link order.
Re: CVS commit: src/sys/conf
According to make(1), $< (${.IMPSRC}) is not set in explicit rules.
If so, existing logic of using explicit rules around ${NORMAL_C} can
be said to be just wrong.
Re: CVS commit: src/sys/conf
Fallouts should not happen.
Re: CVS commit: src/sys
Off course you can do "file if_llatbl.c a|b|c" and leave the burden of fixing modularity for future people. :)
Re: CVS commit: src/sys
sys/netinet/in.c calls a function in sys/net/if_llatbl.c sys/net/if_llatbl.c calls a function in sys/net/if_arp.c This doesn't look very good from modularity POV. Maybe if_llatbl.c should not directly refer to if_arp.c functions.
Re: CVS commit: src/usr.bin/config
Such a hack is needed because config(1) has to generate rules
explicitly for each *.[cS]. If you try to override a rule (e.g.
compile this pmap_bootstrap.c with ${NOPROF_C}), it will be a
duplicated rule.
If *.[cS] -> *.o will be written using suffix rules, you can safely
override rules. No order constraint too.
Re: CVS commit: src/usr.bin/config
And there is $S/../common. Need more thought..
Re: CVS commit: src/usr.bin/config
I will probably allow $S/.. only for `object' paths. To realize suffix rules, I have to dig subdirectories under kernel build directory. But that is only for files that are compiled. I don't need to dig subdirectories for objects whose relative path is `../../../a/b/c'.
Re: CVS commit: src/sys/conf
Sorry, my bad. :(
There seems an evaluation order problem around ${SYSTEM_DEP} ... it is
added to `netbsd' as a dependency much earlier than
`sys/conf/Makefile.kern.inc' is included. I'll simply redo by adding
"netbsd: netbsd.ldscript" in `sys/conf/Makefile.kern.inc' instead of
relying on ${SYSTEM_DEP}.
On Tue, Aug 25, 2015 at 3:02 AM, Christos Zoulas wrote:
> Module Name:src
> Committed By: christos
> Date: Mon Aug 24 18:02:55 UTC 2015
>
> Modified Files:
> src/sys/conf: Makefile.kern.inc
>
> Log Message:
> Fix the build: provide compatibility with ports that define KERNLDSCRIPT to
> a file?
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.188 -r1.189 src/sys/conf/Makefile.kern.inc
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
Re: CVS commit: src/sys/kern
On Fri, Aug 21, 2015 at 3:55 PM, Christos Zoulas wrote: > Module Name:src > Committed By: christos > Date: Fri Aug 21 06:55:25 UTC 2015 > > Modified Files: > src/sys/kern: kern_ksyms.c > > Log Message: > we don't need ioconf.h if we don't have the ksyms pseudo-device This is OK for now but ... quite opposite of modularity.
Re: CVS commit: src/sys/arch/evbarm/conf
Although I confirmed that all kernels of evbearmv7hf-el had no binary changes after this change, I am a bit confused by [1]. According to [1], at that time, this linker script was used by hpcboot (of hpcarm?). Now I see that hpcarm doesn't seem to use linker script at all. Anyway, load addresses, set in the ELF program header, are for external boot loaders. Which means that linker script should be used depending on a boot loader used for a built kernel. There is also a need for linker scripts to be shared as much as possible. Thus separating the SECTIONS command to program load addresses should have some sense. [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/evbarm/conf/ldscript.evbarm?rev=1.5&content-type=text/x-cvsweb-markup
Re: CVS commit: src/sys/arch/netwinder/conf
netwinder is strange in that it wants .data aligned to 0x8000, but it also specifies physical/virtual load addresses as 0xc000/0xf000c000, that are obviously not aligned to 0x8000! Can someone check if other load addresses work? For example 0x0001/0xf001?
Re: CVS commit: src/sys/kern
Can compilers warn that `variables that should not be used are mistakenly used'? If not, marking with `__unused' does not prove that those variables are really unused.
Re: CVS commit: src/sys/kern
Of course I can revert changes but I'd point out that pseudo attach functions were already inconsistent, and I want to fix that inconsistency. Could you list "a number of" other instances that use `int n'? On Wed, Aug 19, 2015 at 11:34 AM, matthew green wrote: > Masao Uebayashi writes: >> On Wed, Aug 19, 2015 at 10:27 AM, Paul Goyette >> wrote: >> (snip) >> > Wasn't the 'n' parameter supposed to be used to tell the driver how many >> > instances of the pseudo-device should be instantiated? At least, for those >> > drivers which do not automatically clone? >> >> Yes. >> >> > Have all of the pseudo-devices been modified to clone? >> >> As I said in another mail, "not yet". > > it looks like raidframe was updated. > > either way, please revert your change. what you have now is > inconsistent and we have two prototypes for the same function > in different headers that conflict. > > that's just confusing. until everything is converted (and > this is a good thing), the current system should remain. > > > .mrg.
Re: CVS commit: src/sys/kern
On Wed, Aug 19, 2015 at 10:27 AM, Paul Goyette wrote: (snip) > Wasn't the 'n' parameter supposed to be used to tell the driver how many > instances of the pseudo-device should be instantiated? At least, for those > drivers which do not automatically clone? Yes. > Have all of the pseudo-devices been modified to clone? As I said in another mail, "not yet".
Re: CVS commit: src/sys/kern
raidattach() doesn't seem to use `int num': http://nxr.netbsd.org/xref/src/sys/dev/raidframe/rf_netbsdkintf.c#395
Re: CVS commit: src/sys/kern
On Wed, Aug 19, 2015 at 5:31 AM, matthew green wrote:
> "Masao Uebayashi" writes:
>> Module Name: src
>> Committed By: uebayasi
>> Date: Tue Aug 18 13:46:20 UTC 2015
>>
>> Modified Files:
>> src/sys/kern: kern_cpu.c kern_drvctl.c
>>
>> Log Message:
>> Convert pseudo attach functions to take no arguments, as some functions
>> (pppattach(), putterattach(), etc.) already do. This means that pseudo
>> attach function will be able to become a constructor.
>
> how does this work?
>
> these functions are called by ioconf.c that generated by config(1),
> so i'm not sure how this can not be a build break, or at least a
> confusing and inconsistent.
>
> ioconf.c:void drvctlattach(int);
> ioconf.c:const struct pdevinit pdevinit[] = {
> ...
> ioconf.c: { drvctlattach, 1 },
>
> subr_autoconf.c: for (pdev = pdevinit; pdev->pdev_attach != NULL; pdev++)
> subr_autoconf.c: (*pdev->pdev_attach)(pdev->pdev_count);
>
> what's the plan here? this reduction won't work for a number of
> basic pdevs (like raid(4)) without updating it to not use the
> count argument.
o I admit I did not check all, but 95% of pseudo attach functions do
not use `int n'.
o I assume that passing an `int' that is ignored by the callee
(func(void)) has proven to be harmless on all CPUs, because it has
worked.
o Killing `int n' is good for reducing kernel build complexity, and
reducing combinations of kernel configs.
o I am (too) optimistic that those pseudo attach functions that use
`int n' can be converted rather easily.
o For the first step, make it clear which functions use `int n' and not.
o If you are really unhappy of the `(void)', I can use `int n __unused'.
Re: CVS commit: src/sys
Which ELF section are splash images located? Are splash images written while running?
Re: CVS commit: src/sys/arch
On Wed, Apr 29, 2015 at 5:32 PM, Hikaru Abe wrote: > Log Message: > Initial import of Cavium Octeon and Octeon Plus SoC and > specifically Ubiquiti Networks EdgeRouter LITE support. > Currently the ethernet and uart of are worked. > This support was contributed by Internet Initiative Japan Inc. USB is working with dwc2 code base on OpenBSD. FYI.
Re: CVS commit: src/share/misc
Are you removing any inappropriate/hostile words in the tree (if exists)?
Re: CVS commit: src
On Mon, Apr 6, 2015 at 7:02 PM, Martin Husemann wrote: > On Sun, Apr 05, 2015 at 09:40:22AM -0400, Christos Zoulas wrote: >> Hmm, it is building things twice... I am trying to figure out why but I can't >> reproduce it. Not surprising at all if multiple output hack (*.y) is involved. > Not sure, but it basically fails for me on all build machines if using low > values for -j. I can get past it by doing a cleandir and dependall without > -j. > > Also below is a log of a non-cleandir'd build failing, but that looks mostly > the same now. If I were you, I'd look at "make -dm" output. (Remember that make(1) has no idea that "foo.c" and "./foo.c" are identical; they are just strings for make(1).)
Re: CVS commit: src/usr.bin/config
Looking. At least, on amd64, the failing tests don't touch "config" at all, according to ktrace(1)...
Re: CVS commit: [nick-nhusb] src/sys/dev/usb
On Sun, Nov 30, 2014 at 10:46 PM, Nick Hudson wrote: > Module Name:src > Committed By: skrll > Date: Sun Nov 30 13:46:00 UTC 2014 > > Modified Files: > src/sys/dev/usb [nick-nhusb]: ehci.c ehcireg.h ehcivar.h > > Log Message: > Add full speed isoc support to ehci(4). Based on the patch posted in > > https://mail-index.netbsd.org/port-arm/2013/04/14/msg001842.html > > From Masao Uebayashi via Sebastien Bocahu The work was actually done by Tsubai Masanari, and also heavily based on FreeBSD's USB stack at that time.
Re: CVS commit: src/sys/net
I predict that in the near future the network stack will act like a "batch" manner; instead of moving layers for a single packet, pass a batch of packets to the next layer; each layer processes a batch of packets in a loop and stay longer (than now) holding a relevant context object cached. In such a model the relative cost of indirection will become nothing.
Re: CVS commit: src/sys/net
On Thu, Nov 27, 2014 at 4:20 PM, Matt Thomas wrote: >> Or completely hide sizeof(struct ifnet) by forcing use of if_alloc(), >> as struct device did. > > Doesn't work since struct ifnet is embedded in ethercom/fddicom Right. I mean, I want to make them alloc'ed to improve modlarity in the long run.
Re: CVS commit: src/sys/net
On Thu, Nov 27, 2014 at 11:39 AM, matthew green wrote: > hiding stuff inside an alloc doesn't really help much when the > kernel code needs to access the structure anyway, unless you > also hide all accesses to the structure inside functions. Right. And some members, including this if_slowtimo_ch, are internal to if.c, which don't affect ABI except struct size.
Re: CVS commit: src/sys/net
On Thu, Nov 27, 2014 at 10:51 AM, Masao Uebayashi wrote: > Maybe adding a few spare members, like 5 pointers, to reduce # of bumps ... ? Or completely hide sizeof(struct ifnet) by forcing use of if_alloc(), as struct device did.
Re: CVS commit: src/sys/net
Maybe adding a few spare members, like 5 pointers, to reduce # of bumps ... ?
CONFIGOPTS
- Add new CONFIGOPTS make variable
- Use CONFIGOPTS where TOOL_CONFIG is used
- Put CONFIGOPTS args first so that other args win
- Revert mkernel/mkernels
Index: build.sh
===
RCS file: /cvsroot/src/build.sh,v
retrieving revision 1.304
diff -p -u -r1.304 build.sh
--- build.sh16 Nov 2014 06:08:13 - 1.304
+++ build.sh25 Nov 2014 08:18:00 -
@@ -1029,8 +1029,6 @@ Usage: ${progname} [-EhnorUuxy] [-a arch
file \`conf'
releasekernel=conf Install kernel built by kernel=conf to RELEASEDIR.
kernels Build all kernels
-mkernelsBuild all kernels in modular build
-mkernel=confBuild kernel with config file \`conf' in modular build
installmodules=idir Run "make installmodules" to \`idir' to install all
kernel modules.
modules Build kernel modules.
@@ -1321,7 +1319,7 @@ parseoptions()
exit $?
;;
- kernel=*|releasekernel=*|kernel.gdb=*|mkernel=*)
+ kernel=*|releasekernel=*|kernel.gdb=*)
arg=${op#*=}
op=${op%%=*}
[ -n "${arg}" ] ||
@@ -1350,7 +1348,6 @@ parseoptions()
iso-image-source|\
iso-image|\
kernels|\
- mkernels|\
live-image|\
makewrapper|\
modules|\
@@ -1987,8 +1984,10 @@ buildkernel()
fi
[ -x "${TOOLDIR}/bin/${toolprefix}config" ] \
|| bomb "${TOOLDIR}/bin/${toolprefix}config does not exist. You need to
\"$0 tools\" first."
- ${runcmd} "${TOOLDIR}/bin/${toolprefix}config" -b "${kernelbuildpath}" \
- ${configopts} -s "${TOP}/sys" "${kernelconfpath}" ||
+ CONFIGOPTS=$(getmakevar CONFIGOPTS)
+ ${runcmd} "${TOOLDIR}/bin/${toolprefix}config" ${CONFIGOPTS} \
+ -b "${kernelbuildpath}" -s "${TOP}/sys" ${configopts} \
+ "${kernelconfpath}" ||
bomb "${toolprefix}config failed for ${kernelconf}"
make_in_dir "${kernelbuildpath}" depend
make_in_dir "${kernelbuildpath}" all
@@ -2250,11 +2249,6 @@ main()
configopts="-D DEBUG=-g"
buildkernel "${arg}"
;;
- mkernel=*)
- arg=${op#*=}
- configopts="-M"
- buildkernel "${arg}"
- ;;
releasekernel=*)
arg=${op#*=}
releasekernel "${arg}"
@@ -2264,11 +2258,6 @@ main()
buildkernels
;;
- mkernels)
- configopts="-M"
- buildkernels
- ;;
-
disk-image=*)
arg=${op#*=}
diskimage "${arg}"
Index: doc/BUILDING.mdoc
===
RCS file: /cvsroot/src/doc/BUILDING.mdoc,v
retrieving revision 1.109
diff -p -u -r1.109 BUILDING.mdoc
--- doc/BUILDING.mdoc 16 Nov 2014 06:10:31 - 1.109
+++ doc/BUILDING.mdoc 25 Nov 2014 08:18:05 -
@@ -1526,12 +1526,6 @@ file alongside of the kernel
which contains a full symbol table and can be used for debugging
(for example with a cross-gdb built by
.Sy MKCROSSGDB ) .
-.It Sy mkernel Ns = Ns Ar kconf
-Build a new kernel in modular build.
-Similar to the above
-.Sy kernel Ns = Ns Ar kconf
-operation, but creates intermediate per-module relocatable objects and link
-them to the final kernel.
.It Sy kernels
This command will build all kernels defined in port specific release build
procedure.
@@ -1539,10 +1533,6 @@ procedure.
This command internally calls the
.Sy kernel Ns = Ns Ar kconf
operation for each found kernel configuration file.
-.It Sy mkernels
-Similar to the above
-.Sy kernels
-operation, but builds kernels in modular build.
.It Sy modules
This command will build kernel modules and install them into
.Sy DESTDIR .
Index: etc/Makefile
===
RCS file: /cvsroot/src/etc/Makefile,v
retrieving revision 1.421
diff -p -u -r1.421 Makefile
--- etc/Makefile10 Aug 2014 05:56:36 - 1.421
+++ etc/Makefile25 Nov 2014 08:18:05 -
@@ -578,7 +578,7 @@ build_kernels: .PHONY
.for configfile in ${ALL_KERNELS} # {
build_kernels: kern-${configfile}
kern-${configfile}: .PHONY .MAKE
- cd ${KERNCONFDIR} && ${TOOL_CONFIG} -s ${KERNSRCDIR} \
+ cd ${KERNCONFDIR} && ${TOOL_CONFIG} ${CONFIGOPTS} -s ${KERNSRCDIR} \
-U DEBUG -b ${KERNOBJDIR}/${configfile:C/.*\///} ${configfile}
.if ${MKUPDATE} == "no"
cd ${KERNOBJDIR}/${configfile:C/.*\///} && ${MAKE} distclean
I
Re: CVS commit: src
How about adding a new make variable CONFIGOPTS, which is passed to config(1)? This name is similar to COPTS and works similarly too.
Re: CVS commit: src
If there is an interface to set arguments to config(1), both "mkernel" and "mkernels" can be reverted. And "kernel.gdb" can be also reverted, I think. On Mon, Nov 17, 2014 at 5:37 PM, Alan Barrett wrote: > On Mon, 17 Nov 2014, Martin Husemann wrote: >> >> On Sun, Nov 16, 2014 at 06:08:13AM +, Masao Uebayashi wrote: >>> >>> Modified Files: >>> src: build.sh >>> >>> Log Message: >>> build.sh mkernels: Build all kernels in modular build >> >> >> Sorry to be slow here, but: >> this "modular" obviously differs from modular kernels (as in: have >> "options >> MODULAR") - so I guess the name is not a good one. I actually have no clue >> what it is supposed to mean. > > > Also, why does it need a new build.sh action? Why can't the choice of how > to build kernels be triggered by a variable in a Makefile or in the > environment or in the kernel configuration? > > Was this discussed anywhere? > > --apb (Alan Barrett)
Re: CVS commit: src
On Mon, Nov 17, 2014 at 5:00 PM, Martin Husemann wrote: > On Sun, Nov 16, 2014 at 06:08:13AM +0000, Masao Uebayashi wrote: >> Module Name: src >> Committed By: uebayasi >> Date: Sun Nov 16 06:08:13 UTC 2014 >> >> Modified Files: >> src: build.sh >> >> Log Message: >> build.sh mkernels: Build all kernels in modular build > > Sorry to be slow here, but: > this "modular" obviously differs from modular kernels (as in: have "options > MODULAR") - so I guess the name is not a good one. I actually have no clue > what it is supposed to mean. There is nothing wrong to link modules statically. Do you have any suggestion of how to call the process of building those modules?
Re: CVS commit: src/sys/conf
On Fri, Nov 14, 2014 at 1:14 AM, Christos Zoulas wrote: > In article > , > Masao Uebayashi wrote: >> >>I can't answer everything soon but one reason coming to mind: >> >>I want to hide all "link_set_*" sections except "link_set_modules" in >>*.kmod. AFAIK linker script doesn't have a syntax to do ``merge >>everything except this pattern''. Thus I need to know all link-set >>sections explicitly. > > Ok, but can't you generate a script dynamically that handles that? I think it is possible.
Re: CVS commit: src/sys/conf
On Fri, Nov 14, 2014 at 12:43 AM, Christos Zoulas wrote: > In article , > Christos Zoulas wrote: >>In article >>, >> >>Can you please explain what you are trying to do and what are your goals? >>I am not sure if I agree that the list of link_sets is "well known". If >>you ask anyone to enumerate them they will probably resort to nm the >>kernel... > > Ok, I see the plan in config now, but I'd still prefer that the link > sets were discovered rather than hard-coded like it has been so far. > What do others think? I can't answer everything soon but one reason coming to mind: I want to hide all "link_set_*" sections except "link_set_modules" in *.kmod. AFAIK linker script doesn't have a syntax to do ``merge everything except this pattern''. Thus I need to know all link-set sections explicitly.
Re: CVS commit: src/sys/conf
On Thu, Nov 13, 2014 at 11:54 PM, Christos Zoulas wrote: > Any solution that involves hard-coding the currently used linksets by > name is no solution for me. Please come up with a complete solution, > and present it for discussion. Yes, the current script is a hack, but > it is a hack we've been using for a while successfully. I would not call it "hard-coding"; link-sets are well-known. All the used link-sets are known before building. I'd detect unknown link-set sections and make that build fail. This is more strict. I'd also provide a way to declare extra link-set for 3rd party modules.
Re: CVS commit: src/sys/conf
On Thu, Nov 13, 2014 at 10:43 PM, Christos Zoulas wrote:
> On Nov 13, 10:28pm, uebay...@gmail.com (Masao Uebayashi) wrote:
> -- Subject: Re: CVS commit: src/sys/conf
>
> | On Thu, Nov 13, 2014 at 10:21 PM, Christos Zoulas
> wrote:
> | > On Nov 13, 10:15pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> | > -- Subject: Re: CVS commit: src/sys/conf
> | >
> | > | I'm not sure about your goal, but anyway it should be proposed
> | > | and discussed proper lists before commit.
> |
> | I have almost no questions, nothing to discuess except details.
> |
> | > | In the perfect world, both cats and shark should have native bootloaders
> | > | that can load native ELF directly and the a.out hack seems a special
> case.
> | >
> | > The script is also used to produce the __{start,stop}_link_set.* symbols
> | > for modules now...
> |
> | I know.
> |
> | And as I said repeatedly, it moves link_set_* sections at wrong places...
>
> It does not matter currently. It is really simple to move them anywhere
> when it makes a difference.
It does not matter for you, it matters for me.
Re: CVS commit: src/sys/conf
On Thu, Nov 13, 2014 at 10:21 PM, Christos Zoulas wrote:
> On Nov 13, 10:15pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> -- Subject: Re: CVS commit: src/sys/conf
>
> | I'm not sure about your goal, but anyway it should be proposed
> | and discussed proper lists before commit.
I have almost no questions, nothing to discuess except details.
> | In the perfect world, both cats and shark should have native bootloaders
> | that can load native ELF directly and the a.out hack seems a special case.
>
> The script is also used to produce the __{start,stop}_link_set.* symbols
> for modules now...
I know.
And as I said repeatedly, it moves link_set_* sections at wrong places...
Re: CVS commit: src/sys/conf
On Wed, Nov 12, 2014 at 11:04 PM, Izumi Tsutsui wrote:
> christos@ wrote:
>
>> I grepped -R and used nxr but found nothing.
>
> Hmm.
> http://nxr.netbsd.org/search?q=mkldscript.sh&project=src
> shows all files..
>
>> >I wonder if you need a different script (or proper wrapper)
>> >for modules..
>>
>> Well, it did not have a valid syntax also when I tried it for some
>> reason (ld complained). It needed:
>>
>> link_set_foo : { *(link_set_foo) }
>>
>> instead of:
>>
>> *(link_set_foo)
>
> The initial commit message says:
> http://mail-index.netbsd.org/source-changes/2004/09/13/msg152610.html
> ---
> Modified Files:
> src/sys/arch/cats/conf: Makefile.cats.inc
> src/sys/arch/shark/conf: Makefile.shark.inc
> src/sys/conf: Makefile.kern.inc
> Added Files:
> src/sys/arch/arm/conf: kern.ldscript.head kern.ldscript.tail
> mkldscript.sh
>
> Log Message:
> work around a binutils bug where converting ELF kernels to a.out with objcopy
> produces corrupted binaries when the link_set_* sections extend into another
> page after the end of the .text section by using a generated an ldscript that
> puts all the link_set_* data into the .text section in the first place.
> ---
>
> You can see how they can be valid in the Makefiles and
> kern.ldscript.{head,tail} files.
>
> Anyway, it looks required for a.out only but no one will fix
> a.out features..
IIUC the requirement for mkldscript.sh users is to merge link_set_*
sections. I'll merge link_set_* into .rodata on all ports. Then this
hack can go away.
(I also found that arm constructor section (.init_array) can't be
converted to a.out too.)
Re: CVS commit: src/share/mk
It'd be better to always generate kldscript and kill *.mk contionals completely.
Re: CVS commit: src/sys/conf
I will look and try to write a separate mkldscript for kmod (but not today).
On Wednesday, November 12, 2014, Izumi Tsutsui
wrote:
> christos@ wrote:
>
> > Module Name: src
> > Committed By: christos
> > Date: Wed Nov 12 02:15:58 UTC 2014
> >
> > Modified Files:
> > src/sys/conf: mkldscript.sh
> >
> > Log Message:
> > I don't know what was using this before
>
> Christos, could you please try at least cvs log or grep -R
> before writing such commit log?
>
> http://mail-index.netbsd.org/source-changes/2007/03/04/0006.html
> ---
> Module Name:src
> Committed By: tsutsui
> Date: Sun Mar 4 02:35:50 UTC 2007
>
> Modified Files:
> src/sys/arch/cats/conf: Makefile.cats.inc
> src/sys/arch/shark/conf: Makefile.shark.inc
> Added Files:
> src/sys/conf: mkldscript.sh
> Removed Files:
> src/sys/arch/arm/conf: mkldscript.sh
>
> Log Message:
> Move mkldscript.sh, which is used to create ldscript dynamically to
> merge link_set_* sections into the text section for a.out kernels,
> from sys/arch/arm/conf/ to sys/conf/ since there is no ARM specific
> stuff in it and other ports would share it.
> ---
>
> % grep -R mkldscript.sh src/sys
> sys/arch/cats/conf/Makefile.cats.inc: OBJDUMP=${OBJDUMP} ${HOST_SH}
> $S/conf/mkldscript.sh \
> sys/arch/luna68k/conf/Makefile.luna68k: OBJDUMP=${OBJDUMP} ${HOST_SH}
> $S/conf/mkldscript.sh \
> sys/arch/shark/conf/Makefile.shark.inc: OBJDUMP=${OBJDUMP} ${HOST_SH}
> $S/conf/mkldscript.sh \
> %
>
> ---
>
> > (but it did not work since it
> > did not produce valid LDSCRIPT code) and now it does.
>
> It have worked more than ten years for these traditional arm ports
> (luna68k no longer needs it since it got a native bootloader though).
>
> I wonder if you need a different script (or proper wrapper)
> for modules..
>
> ---
> Izumi Tsutsui
>
Re: CVS commit: src/sys/conf
You need sizeof(ptr) alignment, not 4. On Wednesday, November 12, 2014, Christos Zoulas wrote: > Module Name:src > Committed By: christos > Date: Wed Nov 12 02:15:58 UTC 2014 > > Modified Files: > src/sys/conf: mkldscript.sh > > Log Message: > I don't know what was using this before (but it did not work since it > did not produce valid LDSCRIPT code) and now it does. > > > To generate a diff of this commit: > cvs rdiff -u -r1.1 -r1.2 src/sys/conf/mkldscript.sh > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > >
Re: CVS commit: src/sys/conf
Now .kmod has .text .data link_set_* .rodata : instead of .text .rodata link_set_* .data : This may work, because modular(9) maps everything as RWX (uvm_km_alloc(UVM_KMF_WIRED | UVM_KMF_EXEC)). But still...
Re: CVS commit: src
Builders will surely be happy to see how the output of "build.sh -m evbearmv7-el kernels" looks like. :)
Re: CVS commit: src/sys/dev
On Thu, Nov 6, 2014 at 4:03 AM, Taylor R Campbell wrote: > Why use a string-keyed table with run-time lookups instead of a C > object with a C declaration? > > /* ioconf.h */ > extern struct cfiattrdata xxxbus; > > /* xxx.c */ > config_found(self, &xxxbus); I tend to prefer indirect lookup to direct reference almost everywhere in config(9). But in this case reference would be fine.
Re: CVS commit: src/sys/dev
On Thu, Nov 6, 2014 at 1:54 AM, Masao Uebayashi wrote:
> struct cfiattrdata {
> const char *ci_name;
> cfprint_t ci_print;
> cfsubmatch_t ci_submatch;
> int ci_loclen;
> const struct cflocdesc ci_locdesc[];
> };
Actually, ci_name, ci_print, ci_submatch are defined in drivers (*.c).
The rest is generated by config(1). But the idea remains.
Re: CVS commit: src/sys/dev
For future reference:
I think any "xxxbus" interface attribute (aka bus) should provide
xxxbusprint (and xxxbussubmatch if multiple children). I'll probably
change config(1) to extend cfiattrdata like:
struct cfiattrdata {
const char *ci_name;
cfprint_t ci_print;
cfsubmatch_t ci_submatch;
int ci_loclen;
const struct cflocdesc ci_locdesc[];
};
Then config_found*() can omit print/submatch args.
If the found child is known (e.g., "pcibus" creating "pci"):
config_found(self, "xxxbus");
If finding unknown children (e.g. "pci" finding pci devices):
config_find(self, "pci", locs, aux);
Re: CVS commit: src/sys/dev
On Tue, Nov 4, 2014 at 1:34 AM, Quentin Garnier wrote: > On Tue, Nov 04, 2014 at 01:16:40AM +0900, Masao Uebayashi wrote: >> On Mon, Nov 3, 2014 at 9:49 PM, Quentin Garnier wrote: >> > On Sat, Nov 01, 2014 at 07:54:18AM +0000, Masao Uebayashi wrote: >> >> Module Name: src >> >> Committed By: uebayasi >> >> Date: Sat Nov 1 07:54:18 UTC 2014 >> >> >> >> Modified Files: >> >> src/sys/dev: audio.c audio_if.h >> >> >> >> Log Message: >> >> Revert previous. >> >> >> >> Not only audio_attach_mi() but also audioprint() have to be separated. >> >> midi.c has the same problem, and a little more complicated. These will be >> >> revisited later. >> > >> > It's because they are functions for "audiobus" (where audio(4) attaches) >> > rather than for "audio". So you can split them into a file that depends >> > on audiobus. >> >> Understood. >> >> Let me reprase: "audiobus" is already an interface attribute. Those >> functions (audio_attach_mi(), audioprint(), ...) will belong to >> audiobus.c (or .o, or .ko). Those drivers providing the "audiobus" >> interface (e.g. auich(4)) will depend on audiobus module. So: >> >> device auich: audiobus, ... >> >> The funny thing here is, the line has two meaning: a) providing >> "audiobus" interface, b) depending on "audiobus" module. Due to the >> limitation of the config(5) syntax! > > I don't see how this particular case is a problem. Why exposing an > audiobus interface wouldn't imply depending on the audiobus-specific > functions? Well, very probably no problem. It's only that I was not 100% sure. >> One question is, when to unload audiobus-as-a-module. It is depended >> on by audio if drivers, but it does not depend on anything. When all >> audio if drivers are unloaded, there is not reason to keep it in >> kernel. Maybe some (smart) ref-counting is needed. > > So you moved on to loadable modules now? I thought your intent was > .text massaging. Just thinking and making sure that I'm not going to break it by design. >> > Most pseudo-buses have that issue I think. Probably some actual buses >> > too. I'd not really expect a kernel that has pchb but not pci selected >> > to compile. >> >> I've not really looked into pseudos yet... > > I meant audiobus. There are a lot of such buses that are not really > anything but a way to attach a generic device. Sure. If I find something odd I'll bring up it somewhere.
Re: CVS commit: src/sys/dev
On Mon, Nov 3, 2014 at 9:49 PM, Quentin Garnier wrote: > On Sat, Nov 01, 2014 at 07:54:18AM +0000, Masao Uebayashi wrote: >> Module Name: src >> Committed By: uebayasi >> Date: Sat Nov 1 07:54:18 UTC 2014 >> >> Modified Files: >> src/sys/dev: audio.c audio_if.h >> >> Log Message: >> Revert previous. >> >> Not only audio_attach_mi() but also audioprint() have to be separated. >> midi.c has the same problem, and a little more complicated. These will be >> revisited later. > > It's because they are functions for "audiobus" (where audio(4) attaches) > rather than for "audio". So you can split them into a file that depends > on audiobus. Understood. Let me reprase: "audiobus" is already an interface attribute. Those functions (audio_attach_mi(), audioprint(), ...) will belong to audiobus.c (or .o, or .ko). Those drivers providing the "audiobus" interface (e.g. auich(4)) will depend on audiobus module. So: device auich: audiobus, ... The funny thing here is, the line has two meaning: a) providing "audiobus" interface, b) depending on "audiobus" module. Due to the limitation of the config(5) syntax! One question is, when to unload audiobus-as-a-module. It is depended on by audio if drivers, but it does not depend on anything. When all audio if drivers are unloaded, there is not reason to keep it in kernel. Maybe some (smart) ref-counting is needed. > Most pseudo-buses have that issue I think. Probably some actual buses > too. I'd not really expect a kernel that has pchb but not pci selected > to compile. I've not really looked into pseudos yet...
Re: CVS commit: src/sys/arch
Reverted.
Re: CVS commit: src/sys/arch
On Mon, Nov 3, 2014 at 2:20 AM, Joerg Sonnenberger
wrote:
> On Mon, Nov 03, 2014 at 01:56:36AM +0900, Masao Uebayashi wrote:
>> On Mon, Nov 3, 2014 at 1:51 AM, Joerg Sonnenberger
>> wrote:
>> > On Mon, Nov 03, 2014 at 01:24:23AM +0900, Masao Uebayashi wrote:
>> >> On Mon, Nov 3, 2014 at 12:12 AM, Joerg Sonnenberger
>> >> wrote:
>> >> > On Sat, Nov 01, 2014 at 11:58:55AM +, Masao Uebayashi wrote:
>> >> >> Module Name: src
>> >> >> Committed By: uebayasi
>> >> >> Date: Sat Nov 1 11:58:55 UTC 2014
>> >> >>
>> >> >> Modified Files:
>> >> >> src/sys/arch/amd64/conf: kern.ldscript kern.ldscript.2MB
>> >> >> kern.ldscript.Xen
>> >> >> src/sys/arch/i386/conf: kern.ldscript kern.ldscript.4MB
>> >> >> kern.ldscript.Xen
>> >> >>
>> >> >> Log Message:
>> >> >> amd64, i386: Don't expose .data.{read_mostly,cacheline_aligned}
>> >> >> sections
>> >> >
>> >> > Huh? There is no reason for such hacks. Please discuss such changes
>> >> > first.
>> >>
>> >> This is how mips ldscript does.
>> >>
>> >> Those two sections are collected and aligned by linker. After doing
>> >> that, is there still any reason to expose the sections? If you point
>> >> out one, I'll revert the changes and document them in the files.
>> >
>> > It makes it harder to look at the kernel image and see which variables
>> > are already optimised? Your change does not improve anything but saving a
>> > few Bytes. That's not an improvement.
>>
>> Is this the only reason you can think of?
>
> It is good enough. You haven't given a reason at all so far.
I thought it was a joke.
I made ldscript much simpler.
Although I'm not convinced at all, I can revert for you.
If you know everything about those ldscripts, I'd appreciate you
rewrite all of them. Thanks.
Re: CVS commit: src/sys/arch
On Mon, Nov 3, 2014 at 1:51 AM, Joerg Sonnenberger
wrote:
> On Mon, Nov 03, 2014 at 01:24:23AM +0900, Masao Uebayashi wrote:
>> On Mon, Nov 3, 2014 at 12:12 AM, Joerg Sonnenberger
>> wrote:
>> > On Sat, Nov 01, 2014 at 11:58:55AM +, Masao Uebayashi wrote:
>> >> Module Name: src
>> >> Committed By: uebayasi
>> >> Date: Sat Nov 1 11:58:55 UTC 2014
>> >>
>> >> Modified Files:
>> >> src/sys/arch/amd64/conf: kern.ldscript kern.ldscript.2MB
>> >> kern.ldscript.Xen
>> >> src/sys/arch/i386/conf: kern.ldscript kern.ldscript.4MB
>> >> kern.ldscript.Xen
>> >>
>> >> Log Message:
>> >> amd64, i386: Don't expose .data.{read_mostly,cacheline_aligned} sections
>> >
>> > Huh? There is no reason for such hacks. Please discuss such changes
>> > first.
>>
>> This is how mips ldscript does.
>>
>> Those two sections are collected and aligned by linker. After doing
>> that, is there still any reason to expose the sections? If you point
>> out one, I'll revert the changes and document them in the files.
>
> It makes it harder to look at the kernel image and see which variables
> are already optimised? Your change does not improve anything but saving a
> few Bytes. That's not an improvement.
Is this the only reason you can think of?
Re: CVS commit: src/sys/arch
On Mon, Nov 3, 2014 at 12:12 AM, Joerg Sonnenberger
wrote:
> On Sat, Nov 01, 2014 at 11:58:55AM +0000, Masao Uebayashi wrote:
>> Module Name: src
>> Committed By: uebayasi
>> Date: Sat Nov 1 11:58:55 UTC 2014
>>
>> Modified Files:
>> src/sys/arch/amd64/conf: kern.ldscript kern.ldscript.2MB
>> kern.ldscript.Xen
>> src/sys/arch/i386/conf: kern.ldscript kern.ldscript.4MB
>> kern.ldscript.Xen
>>
>> Log Message:
>> amd64, i386: Don't expose .data.{read_mostly,cacheline_aligned} sections
>
> Huh? There is no reason for such hacks. Please discuss such changes
> first.
This is how mips ldscript does.
Those two sections are collected and aligned by linker. After doing
that, is there still any reason to expose the sections? If you point
out one, I'll revert the changes and document them in the files.
alpha and arm ldscripts don't define .data.{read_mostly,cacheline_alined}, BTW.
Re: CVS commit: src/usr.bin/config
On Fri, Oct 31, 2014 at 1:49 AM, David Holland wrote: > On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote: > > So, while you expect that "options" works before it's defined, you > > also expect the order is honored for "no" use. I'm not sure how it > > can work internally. > > > > At this moment, "no" are evaluated when it's parsed. Those "no agp*" > > fallouts happened because agp is re-selected while resolving > > dependency after all parsing is done. IMO anything relying on order > > tends to be broken by design. For example: if BAR depends on FOO, "no > > options FOO" has to disable BAR too, because BAR can't be enabled > > without FOO. But when you re-enable FOO, BAR is not enabled. Is this > > really what you're expecting? > > I think it's important not to break the semantics of this. Sure, but this makes me rather depressive.
Re: CVS commit: src/usr.bin/config
On Fri, Oct 31, 2014 at 3:00 AM, Antti Kantee wrote: > On 30/10/14 17:28, Masao Uebayashi wrote: >>> >>> Is there a problem rototilling config is going to solve over what >>> is possible with the existing mechanism (*)? >> >> >> You're welcomed to fix any problems without rotorill and/or breakage. > > > You're not answering the question. For one, to localize related objects (*.o). Now config(1) just collects all *.o and link them into "netbsd". I want to collect for example machdep related objects to be located in the lower address. There might be a way to achieve this without touching config(1). But I think reusing information in config(1) definitions is the most straightforward. (I'll try to state this more clearly in TODO.) >>> *) you probably also heard that rump kernels have constructors with >>> priority levels, implemented using link sets >> >> >> Do you hardcode the priority? > > Yes. They are easy to hardcode, as you can observe from working code, and I > don't see the need for a complex mechanism. There's really only ~10, and > even less for the full kernel, since you don't need to worry about things > like "will vfs be present" or "when do i configure the address for lo0". > Even if you'd want to worry about for example the latter one, how would you > express it with config? The latter is impossible. Module dependency is only about init code order. > But let's consider some magic values are generated by config in a fashion > which works in a non-monolithic build. How will anything be different if > you touch or don't touch linksets, i.e. how is your question relevant in > this discussion? > > Cleaning up init_main() is an ambitious project. I don't know if config is > the right tool for that (I don't know it's _not_, either). I do know that > it's complete orthogonal to how linksets are implemented. I'm discussing multiple things and confusing contexts. My question about linkset is more like: "using linker is good, but why should it be linkset?". I don't understand why their sections are not under .text/.data/.bss. I don't get why their section names have to be exposed in the resulting "netbsd". In any case I'll remove "linkset" part from TODO to not confuse people.
Re: CVS commit: src/usr.bin/config
On Fri, Oct 31, 2014 at 2:28 AM, Masao Uebayashi wrote: > On Fri, Oct 31, 2014 at 1:33 AM, Antti Kantee > wrote: >> On Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote: >>> On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas >>> wrote: >>> > In article <20141030012621.0982...@cvs.netbsd.org>, >>> > Masao Uebayashi wrote: >>> > >>> > Re: constructors/destructors: >>> > >>> > Using them will create a portability constraint on elf. This has >>> > the implication that rump will not work on some platforms. >>> >>> Could you show me an example failure senario? What do you propose instead? >>> >>> I heard that rump fixed linkset problem using .ctors/.dtors. >> >> I heard something different. >> >> A toolchain problem was fixed by using __attribute__((constructor)) >> to reach the contents of link sets in userspace dynamically linked >> environments where generating __start/__stop was not possible. >> Regular link sets are still preferred, as they require less magic >> from the runtime. > > OK. > >> Is there a problem rototilling config is going to solve over what >> is possible with the existing mechanism (*)? > > You're welcomed to fix any problems without rotorill and/or breakage. > >> The problem TODO lists >> is "random ELF sections (with potentially long names) in the final >> kernel". Is that a problem? > > I may misremember it but was it Mach-O specific? The "long name" part > may be irrelevant. But I still *feel* linkset should be done in a > better way. I'll revisit this when I will look closer at moduler vs. > sysctl. pooka@ is always far ahead & already fixed modular-vs-sysctl problems. Now my complaint about linkset is that it doesn't properly put linkset sections under .text/.data/.bss, etc. I also want to utilize linker script in general, as said in TODO.
Re: CVS commit: src/usr.bin/config
On Fri, Oct 31, 2014 at 1:33 AM, Antti Kantee wrote: > On Thu, Oct 30, 2014 at 11:14:50AM +0900, Masao Uebayashi wrote: >> On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas >> wrote: >> > In article <20141030012621.0982...@cvs.netbsd.org>, >> > Masao Uebayashi wrote: >> > >> > Re: constructors/destructors: >> > >> > Using them will create a portability constraint on elf. This has >> > the implication that rump will not work on some platforms. >> >> Could you show me an example failure senario? What do you propose instead? >> >> I heard that rump fixed linkset problem using .ctors/.dtors. > > I heard something different. > > A toolchain problem was fixed by using __attribute__((constructor)) > to reach the contents of link sets in userspace dynamically linked > environments where generating __start/__stop was not possible. > Regular link sets are still preferred, as they require less magic > from the runtime. OK. > Is there a problem rototilling config is going to solve over what > is possible with the existing mechanism (*)? You're welcomed to fix any problems without rotorill and/or breakage. > The problem TODO lists > is "random ELF sections (with potentially long names) in the final > kernel". Is that a problem? I may misremember it but was it Mach-O specific? The "long name" part may be irrelevant. But I still *feel* linkset should be done in a better way. I'll revisit this when I will look closer at moduler vs. sysctl. > *) you probably also heard that rump kernels have constructors with > priority levels, implemented using link sets Do you hardcode the priority?
Re: CVS commit: src/usr.bin/config
On Thu, Oct 30, 2014 at 10:01 PM, Quentin Garnier wrote: > On Thu, Oct 30, 2014 at 09:27:06PM +0900, Masao Uebayashi wrote: >> On Thu, Oct 30, 2014 at 8:36 PM, Alan Barrett wrote: >> > On Thu, 30 Oct 2014, Masao Uebayashi wrote: >> >> >> >> What do you expect by doing: >> >> >> >> options FOO >> >> no options FOO >> >> options FOO >> > >> > I expect it to be equivalent to just one "options FOO". >> > >> > The "no options FOO" in line 2 should cancel the "options FOO" in line 1, >> > and then the "options FOO" in line 3 should put it back. >> > >> > In the cases that I care about, the "options" and "no options" lines will >> > be >> > in different files, referenced via "include" directives. >> >> So, while you expect that "options" works before it's defined, you >> also expect the order is honored for "no" use. I'm not sure how it >> can work internally. >> >> At this moment, "no" are evaluated when it's parsed. Those "no agp*" >> fallouts happened because agp is re-selected while resolving >> dependency after all parsing is done. IMO anything relying on order >> tends to be broken by design. For example: if BAR depends on FOO, "no >> options FOO" has to disable BAR too, because BAR can't be enabled >> without FOO. But when you re-enable FOO, BAR is not enabled. Is this >> really what you're expecting? > > I don't know how it is right now, but options didn't use to depend on > other options so with "options" the case is moot and I would expect the > behaviour Alan describes as correct (this is how it worked the last time > I touched config(1), or at least, was meant to work). OK, my example was confusing, I meant module (attribute-as-module) by "options FOO". Because config(1) has had no way to directly select a module, I abused/extended "options" to select a module. I'm reverting it and adding a generic "select" directive which selects a specified module and its dependency modules. For options, you're right, options (flags/params) don't have dependency. I don't mean to extend it too. I try to address apb@'s item. > For devices, I spent quite a bit of effort making sure "no" behaved the > way Alan expects it. For instance: > > include "GENERIC" > > this* at pci? dev ? fun ? > no device pci > that* at pci? dev ? fun ? > > would emit an error for "that*" but not for "this*". Moreover, without > the last line, none of "this*" or anything pci-related in GENERIC would > actually be selected. I don't fully understand the device part (especially "no" behavior), but I assume they basically expect things are already defined, right? > So if you start making defopt more equivalent to define and allow > "options BAR" to depend on "options FOO", then I would expect > "no options FOO" to cancel a previous "options BAR". > > Otherwise defopt and define used to have very different semantics. I don't mean to make "defopt" (flags/params) to be like "define". (Said so in TODO.) I mean to make "device" (and hopefully "attach") to be more like "define" though.
Re: CVS commit: src/usr.bin/config
On Thu, Oct 30, 2014 at 8:36 PM, Alan Barrett wrote: > On Thu, 30 Oct 2014, Masao Uebayashi wrote: >> >> What do you expect by doing: >> >> options FOO >> no options FOO >> options FOO > > I expect it to be equivalent to just one "options FOO". > > The "no options FOO" in line 2 should cancel the "options FOO" in line 1, > and then the "options FOO" in line 3 should put it back. > > In the cases that I care about, the "options" and "no options" lines will be > in different files, referenced via "include" directives. So, while you expect that "options" works before it's defined, you also expect the order is honored for "no" use. I'm not sure how it can work internally. At this moment, "no" are evaluated when it's parsed. Those "no agp*" fallouts happened because agp is re-selected while resolving dependency after all parsing is done. IMO anything relying on order tends to be broken by design. For example: if BAR depends on FOO, "no options FOO" has to disable BAR too, because BAR can't be enabled without FOO. But when you re-enable FOO, BAR is not enabled. Is this really what you're expecting?
Re: CVS commit: src/usr.bin/config
On Thu, Oct 30, 2014 at 11:38 AM, Matt Thomas wrote: > arm doesn’t use .ctors/.dtors > > it has init/fini array instead. The section names don't really matter. Probably .kctors/.kdtors are less confusing (+ to avoid confliction with rump). > and where would they be executed? Somewhere in sys/kern/init_main.c:main(). Kernel executes modules' constructors. I believe that Linux has already done the same way.
Re: CVS commit: src/usr.bin/config
What do you expect by doing: options FOO no options FOO options FOO ?
Re: CVS commit: src/usr.bin/config
On Thu, Oct 30, 2014 at 10:51 AM, Christos Zoulas wrote: > In article <20141030012621.0982...@cvs.netbsd.org>, > Masao Uebayashi wrote: > > Re: constructors/destructors: > > Using them will create a portability constraint on elf. This has > the implication that rump will not work on some platforms. Could you show me an example failure senario? What do you propose instead? I heard that rump fixed linkset problem using .ctors/.dtors. But .ctors/.dtors in kernel is just analogy of the userland one; it may use the same section names but the internal behavior can be defferent.
Re: CVS commit: src/sys/arch
On Sun, Oct 19, 2014 at 12:15 PM, John Nemeth wrote: > On Oct 18, 4:56pm, "Masao Uebayashi" wrote: > } > } Module Name: src > } Committed By: uebayasi > } Date: Sat Oct 18 16:56:51 UTC 2014 > } > } Modified Files: > } src/sys/arch/amd64/conf: ALL GENERIC XEN3_DOM0 > } src/sys/arch/i386/conf: ALL GENERIC INSTALL_FLOPPY XEN3_DOM0 > } src/sys/arch/x86/pci: files.pci > } > } Log Message: > } Install agp_* drivers where pchb(4) is installed except INSTALL_FLOPPY. > } > } XXX > } Config around agp(4) is done in quite wrong direction. > } "pchb <- (agpbus) <- agp <- agp_*" > } should be: > } "pchb <- (pcibus) <- agp_* <- (agpbus) <- agp" > > No, it should NOT! AGP does NOT hang off a PCI bus. It is a > seperate bus that sits beside PCI. Understood. But still, agp.c is under sys/dev/pci; and its configuration is common to PCI, right? And, agp_* should pass function pointers to agp via attach args so that #ifdef NAGP_* in agp.c can go away.
Re: CVS commit: src/sys/arch/x86/pci
On Sat, Oct 18, 2014 at 5:55 AM, Masao Uebayashi wrote:
> Module Name:src
> Committed By: uebayasi
> Date: Fri Oct 17 20:55:21 UTC 2014
>
> Modified Files:
> src/sys/arch/x86/pci: files.pci
>
> Log Message:
> Fix another indirect circular dependency (agp_* -> (agpbus) -> pchb -> abp_*).
> Fixes "no agp*" build. Reported & build-tested by Kurt Schreiner.
Correction: agp_* -> agp -> (agpbus) -> pchb -> agp_*
Here agpbus is an interface attribute ("bus").
Re: CVS commit: src/sys/arch/amd64/conf
I think this can be fixed by providing new selection statements, "flags" and/or "params", which are meant to enable flags/params, not options/attributes. For ath's case, "options ATHHAL_AR5210" means that you want to include more *.c's for that option. "params ATHHAL_DEBUG" means that you want to change *.o with that flags/params set. In other words, "flags ..." or "params ..." never add *.c and dependencies in your kernel.
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 4:35 AM, Manuel Bouyer wrote:
> On Sun, Oct 12, 2014 at 04:23:17AM +0900, Masao Uebayashi wrote:
>> On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer
>> wrote:
>> > On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote:
>> >> On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer
>> >> wrote:
>> >> > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote:
>> >> >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer
>> >> >> wrote:
>> >> >> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote:
>> >> >> >> Module Name: src
>> >> >> >> Committed By: uebayasi
>> >> >> >> Date: Sat Oct 11 09:50:03 UTC 2014
>> >> >> >>
>> >> >> >> Modified Files:
>> >> >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen
>> >> >> >>
>> >> >> >> Log Message:
>> >> >> >> Don't include std.ath_hal for XEN3_DOMU.
>> >> >> >
>> >> >> > Why ?
>> >> >> > We still support PCI pass-through, so we could have a ath in a domU
>> >> >>
>> >> >> In that case you have to enable xpci/pci at first.
>> >> >>
>> >> >> Including "std.ath_hal" means that you pull in ath device code in your
>> >> >> kernel. But you don't have no parent buses. This might be OK for
>> >> >> ath(4), but in general, it means that config(1) doesn't resolve
>> >> >> dependency, and your kernel may be bloated by unnecessary code.
>> >> >
>> >> > why isn't this compiled in only when ath(4) is inclued in config file ?
>> >> > isn't that what attributes are for ?
>> >>
>> >> I don't understand. If you say "config file", is it files.*
>> >> (definition) or std.* (selection)?
>> >
>> > OK, I see. But I still think config should be able to include theses
>> > only if ath or athn is there; wouldn't adding " & ath" at appropriate
>> > places
>> > in files.ath_hal be enough for this to happen ?
>>
>> Instead of:
>>
>> ath_common_files.c ath & athn
>>
>> You can do:
>>
>> define ath: ath_common
>> define athn: ath_common
>> define ath_common
>> ath_common_files.c ath_common
>>
>> I don't understand why you need & or | or those expressions. I think
>> >99% are file with dependency. Or do you want more complex world like
>> this?
>>
>> http://nxr.netbsd.org/source/xref/src-freebsd/sys/conf/files
>
> No, I just want e.g. "options ATHHAL_AR5210" to be a noop if
> ath(4) is not inclued in the kernel config file.
> This way you don't need to mess with these options at all, unless
> you really want a stripped-down kernel.
Understood.
The problem is, there are options that select something, and those
that define flags/params. Attributes (modules) that are neighter
(pseudo) devices or filesystems are selected only by options.
De-selection ("no ...") has the same problem I'll consider this.
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 3:48 AM, Manuel Bouyer wrote: > On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote: >> On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer >> wrote: >> > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote: >> >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer >> >> wrote: >> >> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: >> >> >> Module Name: src >> >> >> Committed By: uebayasi >> >> >> Date: Sat Oct 11 09:50:03 UTC 2014 >> >> >> >> >> >> Modified Files: >> >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen >> >> >> >> >> >> Log Message: >> >> >> Don't include std.ath_hal for XEN3_DOMU. >> >> > >> >> > Why ? >> >> > We still support PCI pass-through, so we could have a ath in a domU >> >> >> >> In that case you have to enable xpci/pci at first. >> >> >> >> Including "std.ath_hal" means that you pull in ath device code in your >> >> kernel. But you don't have no parent buses. This might be OK for >> >> ath(4), but in general, it means that config(1) doesn't resolve >> >> dependency, and your kernel may be bloated by unnecessary code. >> > >> > why isn't this compiled in only when ath(4) is inclued in config file ? >> > isn't that what attributes are for ? >> >> I don't understand. If you say "config file", is it files.* >> (definition) or std.* (selection)? > > OK, I see. But I still think config should be able to include theses > only if ath or athn is there; wouldn't adding " & ath" at appropriate places > in files.ath_hal be enough for this to happen ? Instead of: ath_common_files.c ath & athn You can do: define ath: ath_common define athn: ath_common define ath_common ath_common_files.c ath_common I don't understand why you need & or | or those expressions. I think >99% are file with dependency. Or do you want more complex world like this? http://nxr.netbsd.org/source/xref/src-freebsd/sys/conf/files
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer wrote: > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote: >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer >> wrote: >> > On Sat, Oct 11, 2014 at 09:50:03AM +, Masao Uebayashi wrote: >> >> Module Name: src >> >> Committed By: uebayasi >> >> Date: Sat Oct 11 09:50:03 UTC 2014 >> >> >> >> Modified Files: >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen >> >> >> >> Log Message: >> >> Don't include std.ath_hal for XEN3_DOMU. >> > >> > Why ? >> > We still support PCI pass-through, so we could have a ath in a domU >> >> In that case you have to enable xpci/pci at first. >> >> Including "std.ath_hal" means that you pull in ath device code in your >> kernel. But you don't have no parent buses. This might be OK for >> ath(4), but in general, it means that config(1) doesn't resolve >> dependency, and your kernel may be bloated by unnecessary code. > > why isn't this compiled in only when ath(4) is inclued in config file ? > isn't that what attributes are for ? I don't understand. If you say "config file", is it files.* (definition) or std.* (selection)?
Re: CVS commit: src/sys/arch/amd64/conf
On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer wrote: > On Sat, Oct 11, 2014 at 09:50:03AM +0000, Masao Uebayashi wrote: >> Module Name: src >> Committed By: uebayasi >> Date: Sat Oct 11 09:50:03 UTC 2014 >> >> Modified Files: >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen >> >> Log Message: >> Don't include std.ath_hal for XEN3_DOMU. > > Why ? > We still support PCI pass-through, so we could have a ath in a domU In that case you have to enable xpci/pci at first. Including "std.ath_hal" means that you pull in ath device code in your kernel. But you don't have no parent buses. This might be OK for ath(4), but in general, it means that config(1) doesn't resolve dependency, and your kernel may be bloated by unnecessary code. (config(1) is not great in reporting dependency errors yet.)
Re: CVS commit: src/sys/arch/evbarm/conf
Probably the default style attachment (like "midi* at midibus?") can (should) be implicity generated.
Re: CVS commit: src/usr.bin/config
My bad. Reproduced here. Hopefully fixed now. On Fri, Oct 10, 2014 at 10:55 PM, Jared McNeill wrote: > Are you able to build the arch/evbarm/conf/CUBIEBOARD kernel with these > changes? > > The kernel config has "options CPU_CORTEXA7", which depends on CPU_CORTEX, > which depends on CPU_ARMV7. Neither CPU_CORTEX nor CPU_ARMV7 are defined in > opt_cputypes.h > > On Fri, 10 Oct 2014, Masao Uebayashi wrote: > >> Date: Fri, 10 Oct 2014 10:22:49 + >> From: Masao Uebayashi >> Reply-To: source-changes-d-qavaossjccednm+yrof...@public.gmane.org >> To: source-changes-full-qavaossjccednm+yrof...@public.gmane.org >> Newsgroups: gmane.os.netbsd.devel.cvs.full >> Followup-To: gmane.os.netbsd.devel.cvs.discuss >> Subject: CVS commit: src/usr.bin/config >> >> >> Module Name:src >> Committed By: uebayasi >> Date: Fri Oct 10 10:22:49 UTC 2014 >> >> Modified Files: >> src/usr.bin/config: main.c >> >> Log Message: >> If an option is selected, select the matching (lowercased) attribute. >> Handle >> dependencies too. >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.60 -r1.61 src/usr.bin/config/main.c >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files. >> >> >
Re: CVS commit: src/sys/conf
config(5) is made of definitions and selections. Selections are basically written in user's config (GENERIC, etc.); commen ones may be put in sys/conf/std or sys/arch/*/conf/std.*. To follow that naming convention, how about: sys/conf/all.filesystems sys/conf/all.usb ? Users have to filter unwanted ones by the "no ..." syntax. If that will not work, config(1) needs to be fixed. :)
Re: CVS commit: src/sys
Not objecting this paricular change, but I hope that sys/sysctl.h be less loaded, ideally porviding only sysctl base definitions, than more loaded...
Re: CVS commit: src/distrib/sets
On Thu, May 29, 2014 at 5:09 PM, Alan Barrett wrote: > On Sat, 24 May 2014, Masao Uebayashi wrote: >> >> Log Message: >> Unbreak syspkg by escaping '[' by vis(1) to match the new mtree(8) format. > > I'd prefer to escape using TOOL_SED so we don't need to add a new TOOL_VIS. Fine with me.
Re: CVS commit: src/sys
On Tue, May 27, 2014 at 6:31 AM, Antti Kantee wrote: > On 26/05/14 19:38, David Holland wrote: >> >> On Sun, May 25, 2014 at 04:31:51PM +, Antti Kantee wrote: >> > Modified Files: >> > src/sys/kern: subr_devsw.c vfs_bio.c >> > src/sys/rump/librump/rumpkern: rump.c >> > >> > Log Message: >> > Call biodone() in the bdev_strategy() error via a pointer. Decouples >> > subr_devsw from VFS -- not that I/O buffers are _VFS_ entities -- >> >> Yes they are... so are devsw entries, for that matter. > > > Fact: tcp/ip + bpf (accessed via devsw) works fine without VFS. Let's keep > it that way. E.g. IoT folks looking at using the NetBSD TCP/IP stack in This is really nice! > their [high-end] devices wouldn't be too thrilled if the memory requirement > for networking grew by 100% just because. If an OS can run with 1/2 memory, the number of (virtual) instances can be doubled, which is a big win in this era. :)
Re: CVS commit: src/sys/arch/amd64/amd64
On Tue, May 13, 2014 at 2:28 AM, Jonathan A. Kollasch wrote: > On Mon, May 12, 2014 at 07:05:29PM +0200, Joerg Sonnenberger wrote: >> On Mon, May 12, 2014 at 01:49:24PM +0000, Masao Uebayashi wrote: >> > Module Name:src >> > Committed By: uebayasi >> > Date: Mon May 12 13:49:24 UTC 2014 >> > >> > Modified Files: >> > src/sys/arch/amd64/amd64: machdep.c >> > >> > Log Message: >> > Don't reserve space (128) on signal stack for unknown reasons; the actual >> > space for struct sigframe_siginfo (+ alignment) is allocated just below. >> >> AMD64 uses a redzone, so the compiler can put up to 128 Bytes on the >> stack without having to adjust RSP. Please revert immediately. > > Done. Thanks. I left a comment there.
Re: CVS commit: src/sys/arch/i386/stand
Stripping eh_frame using linker script, without adding unusal gcc options, looks much simpler as a whole picture to me. On Fri, May 2, 2014 at 3:37 AM, David Laight wrote: > Module Name:src > Committed By: dsl > Date: Thu May 1 18:37:26 UTC 2014 > > Modified Files: > src/sys/arch/i386/stand: Makefile.inc > > Log Message: > Add -fno-asynchronous-unwind-tables -fno-exceptions to gcc builds. > One of these (probably the first) is needed to stop the eh-frame > section being created. > The eh_frame section is loadable and bloats the boot images. > This might be enough to make pxeboot work. > > > To generate a diff of this commit: > cvs rdiff -u -r1.11 -r1.12 src/sys/arch/i386/stand/Makefile.inc > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src
Thanks. I will revisit this later. On Tuesday, April 29, 2014, Antti Kantee wrote: > On Tue, Apr 29, 2014 at 06:51:57AM +0000, Masao Uebayashi wrote: > > Module Name: src > > Committed By: uebayasi > > Date: Tue Apr 29 06:51:57 UTC 2014 > > > > Modified Files: > > src: build.sh > > > > Log Message: > > resolvepath: Resolve .. in absolute paths. > > > > > > To generate a diff of this commit: > > cvs rdiff -u -r1.278 -r1.279 src/build.sh > > This breaks ./build.sh -w >
Re: CVS commit: src/sys/arch/powerpc/conf
Hopefully kernel entry (locore.o) is placed using ldscript so that stupid *.o ordering in makefiles can go away? On Sat, Apr 19, 2014 at 9:46 PM, Matt Thomas wrote: > Module Name:src > Committed By: matt > Date: Sat Apr 19 12:46:04 UTC 2014 > > Added Files: > src/sys/arch/powerpc/conf: kern64.ldscript > > Log Message: > ldscript for ppc64 kernels > > > To generate a diff of this commit: > cvs rdiff -u -r0 -r1.1 src/sys/arch/powerpc/conf/kern64.ldscript > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/sys/kern
On Sun, Apr 13, 2014 at 12:33 AM, Nick Hudson wrote:
> On 04/12/14 16:08, Masao Uebayashi wrote:
>>
>> Module Name:src
>> Committed By: uebayasi
>> Date: Sat Apr 12 15:08:56 UTC 2014
>>
>> Modified Files:
>> src/sys/kern: kern_exec.c
>>
>> Log Message:
>> execve_runproc: Correct thinko in Rev. 1.386; the new SP always points to
>> after (higher adderss) argc/argv/env/aux/strings regardless of stack
>> growing
>> direction .
>
> Doesn't this mean that argc, etc will get overwritten on _rtld_start call
> for stack grows down machines?
>
> SP needs to point to the first available stack address. On stack grows down
> machines this is a lower value than argc, etc. On stack grows up machines
> this is a higher value.
http://www.netbsd.org/~uebayasi/execve-stack-growdown.pdf
http://www.netbsd.org/~uebayasi/execve-stack-growup.pdf
Initial SP points to STACK_GROW(minsaddr, ssize). rtld can use the
given stack freely (contradicting obsolete comments found in
kern_exec.c).
stack-growing-up rtld has to figure out &argc. This is possible by
(vaddr_t)ps_argvstr - (vaddr_t)sizeof(argc). Note that argc on stack
is long (== char *), not int. hppa's rtld assumes int, which has to
be fixed for hppa64.
http://nxr.netbsd.org/xref/src/libexec/ld.elf_so/arch/hppa/rtld_start.S#88
> btw, why do you keep adding 4 space idented { } ?
To narrow local var scopes. They should go away eventually...
Re: CVS commit: src/share/mk
How about kernel modules? On Fri, Jan 24, 2014 at 1:00 PM, matthew green wrote: > >> Is this all about symlink-to-directory in an OBJDIR, right? My theory >> is that directory creation in OBJDIR is all wrong... >> >> Kernel build *should* include static headers in $DESTDIR (#include >> ) or generated headers (#include "foo.h") IMO. > > the kernel build 100% does not and should not depend upon $DESTDIR. > > > .mrg.
Re: CVS commit: src/distrib/sets
I agree that in an ideal reproducible world timestamp (== physical time and its order) has no value. But it is useful to detect "unnecessary rebuild" - reproducible but built repeatedly & unnecessarily. I see some value in it. On Fri, Jan 24, 2014 at 6:45 AM, Alan Barrett wrote: > Module Name:src > Committed By: apb > Date: Thu Jan 23 21:45:27 UTC 2014 > > Modified Files: > src/distrib/sets: Makefile > > Log Message: > Remove time= keywords from METALOG.sanitised. > > The times add unnecessary differences to the DESTDIR trees for MKREPRO > builds, and they are not needed by anything. (maketars, the chief > consumer of METALOG.sanitised, explicitly ignores the time fields.) > > Also factor out some duplicated code and update comments. > > > To generate a diff of this commit: > cvs rdiff -u -r1.91 -r1.92 src/distrib/sets/Makefile > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/share/mk
Sorry that I was lost, but I still believe that creating-directories-as-make-target is to avoid. Is there any counter-example (use case) where it should be there? On Fri, Jan 24, 2014 at 1:30 AM, Izumi Tsutsui wrote: >> Is this all about symlink-to-directory in an OBJDIR, right? My theory >> is that directory creation in OBJDIR is all wrong... >> >> Kernel build *should* include static headers in $DESTDIR (#include >> ) or generated headers (#include "foo.h") IMO. > > is used only for standalone programs > and it should not require installed DESTDIR. > > For kernel builds, config(1) creates symlinks in compile dirs. > > --- > Izumi Tsutsui
Re: CVS commit: src/share/mk
Is this all about symlink-to-directory in an OBJDIR, right? My theory is that directory creation in OBJDIR is all wrong... Kernel build *should* include static headers in $DESTDIR (#include ) or generated headers (#include "foo.h") IMO.
Re: CVS commit: src/share/mk
I wonder if "ln -sfh" is portable? On Thu, Jan 23, 2014 at 12:23 PM, Christos Zoulas wrote: > On Jan 23, 3:11am, campbell+netbsd-source-change...@mumble.net (Taylor R > Campbell) wrote: > -- Subject: Re: CVS commit: src/share/mk > > |Date: Wed, 22 Jan 2014 13:15:44 -0500 > |From: chris...@zoulas.com (Christos Zoulas) > | > |On Jan 22, 7:29am, m...@3am-software.com (Matt Thomas) wrote: > |-- Subject: Re: CVS commit: src/share/mk > | > || I always wondered why we don't use ln -sf > || and avoid the race. > | > |That does not work because if the destnation is a directory it will > |try to link in the destination directory... (I tried). This is why > |I suggested that it needs to be done differently. > | > | ln -sfh? > | > | As an aside, it would be nice if there were an easy way to create a > | symlink at a temporary location and rename it over the permanent one. > | `ln -sfh' will unlink instead, and mv(1) is too smart for its own good > | about directories to be able to rename over a symlink reliably... > > > Yes perhaps that will work. > > christos
Re: CVS commit: src/sys/arch
Because I don't want to change resulting binaries (*.o) for now. I think I'll "switch" these when cleaned up and merged and moved to sys/arch/x86. How do you think? On Tue, Jun 25, 2013 at 12:17 PM, YAMAMOTO Takashi wrote: > hi, > > why do you need to make *.S include another *.S > rather than tweaking makefile? > > YAMAMOTO Takashi > >> Module Name: src >> Committed By: uebayasi >> Date: Tue Jun 25 00:27:22 UTC 2013 >> >> Modified Files: >> src/sys/arch/amd64/amd64: vector.S >> src/sys/arch/i386/i386: vector.S >> Added Files: >> src/sys/arch/amd64/amd64: amd64_trap.S >> src/sys/arch/i386/i386: i386_trap.S i386_trap_ipkdb.S >> >> Log Message: >> Split these to improve diffability. >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r0 -r1.1 src/sys/arch/amd64/amd64/amd64_trap.S >> cvs rdiff -u -r1.43 -r1.44 src/sys/arch/amd64/amd64/vector.S >> cvs rdiff -u -r0 -r1.1 src/sys/arch/i386/i386/i386_trap.S \ >> src/sys/arch/i386/i386/i386_trap_ipkdb.S >> cvs rdiff -u -r1.61 -r1.62 src/sys/arch/i386/i386/vector.S >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files.
Re: CVS commit: [agc-symver] src/lib/libc
I'm not sure if symbols like _citrus_* are meant to be exported as global. Probably not.
Re: CVS commit: [agc-symver] src/lib/libc
How do you generate Version.map? Can you define symbols per-module (e.g., libc/gen, libc/stdio, ...)?
Re: CVS commit: src/usr.bin/make
I like make(1) to exit when stale depend is found. On Tue, Mar 5, 2013 at 11:04 AM, Christos Zoulas wrote: > Module Name:src > Committed By: christos > Date: Tue Mar 5 02:04:11 UTC 2013 > > Modified Files: > src/usr.bin/make: dir.c job.c parse.c > > Log Message: > Keep track of the location where a dependency is defined, so we can report > about it. > > > To generate a diff of this commit: > cvs rdiff -u -r1.65 -r1.66 src/usr.bin/make/dir.c > cvs rdiff -u -r1.170 -r1.171 src/usr.bin/make/job.c > cvs rdiff -u -r1.185 -r1.186 src/usr.bin/make/parse.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > >
