On Mon, Sep 16, 2019 at 03:39:35AM +0200, Emmanuel Dreyfus wrote:
> Thor Lancelot Simon wrote:
>
> > I've never been a fan of the wedge: syntax (as was noted at the time, it
> > conflicts with the syntax for specifying network filesystem servers,
> > which actually broke automation I had in
Thor Lancelot Simon wrote:
> I've never been a fan of the wedge: syntax (as was noted at the time, it
> conflicts with the syntax for specifying network filesystem servers,
> which actually broke automation I had in place); I would not mind seeing
> it go.
IMO, both wedge: and NAME= are ugly,
m...@netbsd.org (Emmanuel Dreyfus) writes:
>Michael van Elst wrote:
>> We have to decide if we really want to switch things to the NAME=
>> syntax and allow wedge: only for compatibility.
>I went for NAME= here because x86 bootloader now uses that everywhere,
>and my concern was multiboot
Michael van Elst wrote:
> We have to decide if we really want to switch things to the NAME=
> syntax and allow wedge: only for compatibility.
I went for NAME= here because x86 bootloader now uses that everywhere,
and my concern was multiboot command line root options passed as is from
On Sun, Sep 15, 2019 at 03:47:32AM +0200, Emmanuel Dreyfus wrote:
> Michael van Elst wrote:
>
> > A real solution would just support the NAME=* syntax in getwedgename().
> > It might also allow for a case-insensitive match like userland. Then
> > it would just work for config, for boot
Michael van Elst wrote:
> A real solution would just support the NAME=* syntax in getwedgename().
> It might also allow for a case-insensitive match like userland. Then
> it would just work for config, for boot parameters and for interactive
> entries.
You mean this change?
---
Martin Husemann wrote:
> Oh, *B*ootdev vs. *R*ootdev - I see.
> Not sure why bootdev is important, however we should use the same syntax!
The change handles the parameter passed from bootloader when booting
Xen. In boot.cfg, NAME=label is now supported everywhere, and this was
the only missing
mar...@duskware.de (Martin Husemann) writes:
>> config netbsd root on "wedge:Guru-Root" type ffs
>> for ages (in the netbsd-7 branch even).
>Oh, *B*ootdev vs. *R*ootdev - I see.
>Not sure why bootdev is important, however we should use the same syntax!
bootdev already
On Sat, Sep 14, 2019 at 06:26:34AM +, Martin Husemann wrote:
> > Log Message:
> > Accept root device specification as NAME=label
[..]
> Why is this needed?
>
> I have been using
>
> config netbsd root on "wedge:Guru-Root" type ffs
>
> for ages (in the netbsd-7
On Fri, Sep 13, 2019 at 01:33:20AM +, Emmanuel Dreyfus wrote:
> Module Name: src
> Committed By: manu
> Date: Fri Sep 13 01:33:20 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_subr.c
>
> Log Message:
> Accept root device specification as NAME=label
>
>
> To generate a
In article <8998.1530490...@splode.eterna.com.au>,
matthew green wrote:
>Jason Thorpe writes:
>>
>>
>> > On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote:
>> >
>> > I'd rather not have this at all - instead just drop the useless timestamps
>> > at boot time, they are useless here and make
Jason Thorpe writes:
>
>
> > On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote:
> >
> > I'd rather not have this at all - instead just drop the useless timestamps
> > at boot time, they are useless here and make console output unreadable.
> >
> > They are fine after mountroot, but is there
> On Jul 1, 2018, at 2:48 AM, Martin Husemann wrote:
>
> I'd rather not have this at all - instead just drop the useless timestamps
> at boot time, they are useless here and make console output unreadable.
>
> They are fine after mountroot, but is there really any use for them before?
+1
On Sat, Jun 30, 2018 at 10:47:51PM +, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Sat Jun 30 22:47:51 UTC 2018
>
> Modified Files:
> src/sys/kern: kern_ntptime.c kern_tc.c
>
> Log Message:
> Sprinkle cold conditionals to make tc_ticktock
On Tue, Aug 25, 2015 at 03:59:00PM +0300, Andreas Gustafsson wrote:
Martin Husemann wrote:
I have another evbarm machine now hanging as well, so it is not just alpha.
The sparc test runs on babylon5 are affected, too. I just committed a
fix, let's see if it works.
Alpha worked, will
Martin Husemann wrote:
I have another evbarm machine now hanging as well, so it is not just alpha.
The sparc test runs on babylon5 are affected, too. I just committed a
fix, let's see if it works.
--
Andreas Gustafsson, g...@netbsd.org
On Wed, Aug 19, 2015 at 12:02:55PM +, Andreas Gustafsson wrote:
Module Name: src
Committed By: gson
Date: Wed Aug 19 12:02:55 UTC 2015
Modified Files:
src/sys/kern: tty.c
Log Message:
When closing a tty, limit the amount of time spent waiting for the
output to drain
In article 20140725195305.55fbb14a...@mail.netbsd.org,
Mindaugas Rasiukevicius rm...@netbsd.org wrote:
chris...@astron.com (Christos Zoulas) wrote:
In article 53d288c7.5000...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Well, if only these architectures are running with DIAGNOSTIC,
On Sun, Jul 27, 2014 at 07:37:14PM +, Christos Zoulas wrote:
to wrap all the KMEM_ related diagnostic options in one, can separate
them from DIAGNOSTIC, so that low memory machines can choose not to turn
them on, but still have DIAGNOSTIC turned on.
I am not convinced this will be used
On Jul 27, 9:46pm, mar...@duskware.de (Martin Husemann) wrote:
-- Subject: Re: CVS commit: src/sys/kern
| On Sun, Jul 27, 2014 at 07:37:14PM +, Christos Zoulas wrote:
| to wrap all the KMEM_ related diagnostic options in one, can separate
| them from DIAGNOSTIC, so that low memory machines
In article 53d22353.9090...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Le 23/07/2014 21:51, Greg Troxel a écrit :
I realized that two things can be separated. One is whether DIAGNOSTIC
turns on features that increase the size of memory allocations, which is
my real concern. The
Le 25/07/2014 16:51, Christos Zoulas a écrit :
In article 53d22353.9090...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Le 23/07/2014 21:51, Greg Troxel a écrit :
I realized that two things can be separated. One is whether DIAGNOSTIC
turns on features that increase the size of
In article 53d288c7.5000...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Well, if only these architectures are running with DIAGNOSTIC, that's not a
big deal. Anyway, let's put KMEM_DIAGNOSTIC.
I like KMEM_DIAGNOSTIC, can you add it, or should I?
christos
chris...@astron.com (Christos Zoulas) wrote:
In article 53d288c7.5000...@m00nbsd.net,
Maxime Villard m...@m00nbsd.net wrote:
Well, if only these architectures are running with DIAGNOSTIC, that's
not a big deal. Anyway, let's put KMEM_DIAGNOSTIC.
I like KMEM_DIAGNOSTIC, can you add it, or
I realized that two things can be separated. One is whether DIAGNOSTIC
turns on features that increase the size of memory allocations, which is
my real concern. The other is whether the KMEM_SIZE and KMEM_REDZONE
should be on by default in -current on various architectures, which is I
think
Maxime Villard m...@netbsd.org writes:
Module Name: src
Committed By: maxv
Date: Tue Jul 22 07:38:41 UTC 2014
Modified Files:
src/sys/kern: subr_kmem.c
Log Message:
Enable KMEM_REDZONE on DIAGNOSTIC. It will try to catch overflows.
No comment on tech-kern@
I didn't see
Nick Hudson sk...@netbsd.org writes:
On 07/22/14 12:49, Greg Troxel wrote:
Maxime Villard m...@netbsd.org writes:
Module Name:src
Committed By: maxv
Date: Tue Jul 22 07:38:41 UTC 2014
Modified Files:
src/sys/kern: subr_kmem.c
Log Message:
Enable
On 07/22/14 12:49, Greg Troxel wrote:
Maxime Villard m...@netbsd.org writes:
Module Name:src
Committed By: maxv
Date: Tue Jul 22 07:38:41 UTC 2014
Modified Files:
src/sys/kern: subr_kmem.c
Log Message:
Enable KMEM_REDZONE on DIAGNOSTIC. It will try to catch overflows.
On Tue, Jul 22, 2014 at 12:54:15PM +0100, Nick Hudson wrote:
I'd guess that KMEM_REDZONE add much less than 15%.
Even if 15% were a value we'd be willing to tolerate (which I doubt),
that's 15% total, not 15% each.
Anyway, rather than shouting, can someone check what it really does
cost?
--
On Wed, Mar 05, 2014 at 06:04:02PM +0200, Andreas Gustafsson wrote:
2. I also object to the change of kern_syctl.c 1.247.
This change attempts to work around the problems caused by the changes
to the variable types by making sysctl() return different types
depending on the value of the
On Tue, Aug 27, 2013 at 02:01:36PM +, Taylor R Campbell wrote:
This is a stop-gap on a stop-gap on a stop-gap; we really ought to
back out all of these stop-gaps, make bcm2835_rng call rnd_add_data
asynchronously to work around the original symptom, and design a real
solution when we
31 matches
Mail list logo
