On 09/09/2016 22:09, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Sep 9 21:09:11 UTC 2016
>
> Modified Files:
> src/usr.bin/config: defs.h files.c sem.c
>
> Log Message:
> Make attribute deselection work:
> - when deselecting attributes, remove fi
Masao Uebayashi writes:
> 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 optio
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
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
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
On Sat, Aug 29, 2015 at 12:03:51PM +0900, Masao Uebayashi wrote:
> 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] -> *.
"Masao Uebayashi" writes:
> Module Name: src
> Committed By: uebayasi
> Date: Fri Aug 28 08:31:28 UTC 2015
>
> Modified Files:
> src/usr.bin/config: mkmakefile.c
>
> Log Message:
> Accept only relative paths (from $S) for `file' and `object'. Simplify code.
> config(1) does not ne
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 orde
On Fri, Aug 28, 2015 at 08:31:28AM +, Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Fri Aug 28 08:31:28 UTC 2015
>
> Modified Files:
> src/usr.bin/config: mkmakefile.c
>
> Log Message:
> Accept only relative paths (from $S) for `file' and `object'.
And there is $S/../common. Need more thought..
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'.
Looking. At least, on amd64, the failing tests don't touch "config"
at all, according to ktrace(1)...
On Tue, Dec 16, 2014 at 12:49 AM, Masao Uebayashi wrote:
> Module Name:src
> Committed By: uebayasi
> Date: Mon Dec 15 15:49:25 UTC 2014
>
> Modified Files:
> src/usr.bin/config: mkmakefile.c
>
> Log Message:
> Revert debug code. Simplify.
http://releng.netbsd.org/b5repor
On Thu, 30 Oct 2014, Taylor R Campbell wrote:
It seems to me that while depending on ordering for definitions,
files, &c., may be no good, for selections the language of
include "GENERIC"
no options DIAGNOSTIC
no agp*
is still valuable.
I don't mind how it's implemented, but my main concern i
Date: Fri, 31 Oct 2014 03:36:45 +0900
From: Masao Uebayashi
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:
> > At this moment, "no" are evaluated when it's parsed. Those "no agp*"
> > fallouts happe
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.
> >
>
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.
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.netb
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.
*) you probably also heard that r
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/
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
>>
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 "n
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 constra
In article <54522b88.7060...@gmail.com>,
Takahiro HAYASHI wrote:
>On 10/30/14 10:36, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Oct 30 01:36:13 UTC 2014
>>
>> Modified Files:
>> src/usr.bin/config: mkheaders.c
>>
>> Log Message:
>>
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 equ
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 t
On 10/30/14 10:36, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Thu Oct 30 01:36:13 UTC 2014
Modified Files:
src/usr.bin/config: mkheaders.c
Log Message:
print more info about the overflow
It panics on amd64 when negative value is specified like
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
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/k
> On Oct 29, 2014, at 7:30 PM, Christos Zoulas wrote:
>
> On Oct 30, 11:14am, uebay...@gmail.com (Masao Uebayashi) wrote:
> -- Subject: Re: CVS commit: src/usr.bin/config
>
> | Could you show me an example failure senario? What do you propose instead?
>
> I don
On Oct 30, 11:14am, uebay...@gmail.com (Masao Uebayashi) wrote:
-- Subject: Re: CVS commit: src/usr.bin/config
| Could you show me an example failure senario? What do you propose instead?
I don't have anything *better* to propose. I think mach-o constructors
are different.
| I heard that
What do you expect by doing:
options FOO
no options FOO
options FOO
?
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 platform
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.
christos
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.
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:
On Thu, Oct 09, 2014 at 07:20:56PM +, Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Thu Oct 9 19:20:56 UTC 2014
>
> Modified Files:
> src/usr.bin/config: defs.h main.c mkmakefile.c
>
> Log Message:
> Steal -M to enable "modular" build.
Can you ple
On Nov 1, 11:04pm, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: CVS commit: src/usr.bin/config
| On Fri, Nov 01, 2013 at 13:09:59 -0400, Christos Zoulas wrote:
|
| > Module Name:src
| > Committed By: christos
| > Date: Fri Nov 1 17:09:59
On Fri, Nov 01, 2013 at 13:09:59 -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Fri Nov 1 17:09:59 UTC 2013
>
> Modified Files:
> src/usr.bin/config: main.c util.c
>
> Log Message:
> make config errors look more like other programs: ,:
> instead
On Aug 31, 12:02am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/usr.bin/config
| Probably it's better to use #if !defined(HAVE_NBTOOL_CONFIG_H)
| rather than #ifdef __NetBSD__ ?
I'll have to think about it a little more (i.e. what's the scena
> Modified Files:
> src/usr.bin/config: config.1 main.c
>
> Log Message:
> make config -x look at the booted kernel first.
Probably it's better to use #if !defined(HAVE_NBTOOL_CONFIG_H)
rather than #ifdef __NetBSD__ ?
---
Izumi Tsutsui
> if_fxp_pci.kmod -> pci.kmod
This should have been:
if_fxp_pci.kmod -> pciif.kmod
Device modules have dependency on an interface. But the instances (fxp0)
are attached to parent devices (fxp0 at pci0). Problem is when you load
if_fxp_pci.kmod without having pci.kmod or something
> That there should be a way to inject cfdata at run-time (well, along
> with loading a module), yes.
Good.
> That anything should be moved back to drivers' .c file, not really. The
> information carried by a line like "device pci { dev = -1,
> function = -1 }" is no different to a function prot
On Tue, Mar 02, 2010 at 10:10:15AM +0900, Masao Uebayashi wrote:
> > > I'm considering to move cfdata[] and *_iattrdata to each driver's *.c.
> > > Maybe
> >
> > That would be a huge step back. Do *NOT* do that.
>
> Oops. I meant s/cfdata/cfdriver/.
>
> In the long run, templates are moved i
> > I'm considering to move cfdata[] and *_iattrdata to each driver's *.c.
> > Maybe
>
> That would be a huge step back. Do *NOT* do that.
Oops. I meant s/cfdata/cfdriver/.
In the long run, templates are moved into *.c, and true configuration (direct
config / user config == cfdata) is loaded
On Mon, Mar 01, 2010 at 05:28:15PM +0900, Masao Uebayashi wrote:
[...]
> I'm considering to move cfdata[] and *_iattrdata to each driver's *.c. Maybe
That would be a huge step back. Do *NOT* do that.
--
Quentin Garnier - c...@cubidou.net - c...@netbsd.org
"See the look on my face from staying
On Mon Mar 01 2010 at 17:28:15 +0900, Masao Uebayashi wrote:
> > Log Message:
> > Introduce experimental support for ioconf-only configuration files.
> > This is done by giving the "ioconf" keyword in the config file.
> > As a result, config produces only ioconf.c and locators.h. Currently,
> > on
> Log Message:
> Introduce experimental support for ioconf-only configuration files.
> This is done by giving the "ioconf" keyword in the config file.
> As a result, config produces only ioconf.c and locators.h. Currently,
> only "monolithic" configurations with the device path starting from
> roo
48 matches
Mail list logo
