On Fri, Apr 19, 2024 at 10:48:10PM +0700, Robert Elz wrote:
> Date:Fri, 19 Apr 2024 14:58:18 +
> From:"Jonathan A. Kollasch"
> Message-ID: <20240419145818.351d2f...@cvs.netbsd.org>
>
> | - bail out if resulting __DATE__/__TIME__ replacement strings are empty
>
Date:Fri, 19 Apr 2024 14:58:18 +
From:"Jonathan A. Kollasch"
Message-ID: <20240419145818.351d2f...@cvs.netbsd.org>
| - bail out if resulting __DATE__/__TIME__ replacement strings are empty
If you want to do that (not that it would be useful, even if the %b
On Fri 19 Apr 2024 at 14:47:23 +0200, Martin Husemann wrote:
> The problem (IIUC) is that the ntp code parses this value internally, so
> it won't talk to anyone claiming a time before the time ntpd was compiled
> (or something along that line).
Would it make sense to just supply a fixed string
Date:Fri, 19 Apr 2024 14:57:46 +0200
From:Martin Husemann
Message-ID: <20240419125746.gb26...@mail.duskware.de>
| On Fri, Apr 19, 2024 at 02:47:23PM +0200, Martin Husemann wrote:
| > The commit message could have explained that a bit.
|
| And it actually
On Fri, Apr 19, 2024 at 02:47:23PM +0200, Martin Husemann wrote:
> The commit message could have explained that a bit.
And it actually should have been "+%b %e %Y" - from the C18 standard draft:
6.10.8.1 Mandatory macros
__DATE__
The date of translation of the preprocessing translation unit:
On Fri, Apr 19, 2024 at 04:36:46PM +0700, Robert Elz wrote:
> I don't understand that change, it altered from
>
> MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%F"
> to
> MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%b %d %Y"
>
> %F is simply a shorthand
Date:Thu, 18 Apr 2024 19:23:54 +
From:"Jonathan A. Kollasch"
Message-ID: <20240418192354.1bcc1f...@cvs.netbsd.org>
| Module Name:src
| Committed By: jakllsch
| Date: Thu Apr 18 19:23:54 UTC 2024
|
| Modified Files:
|
maya@ wrote:
> Module Name: src
> Committed By: maya
> Date: Tue Apr 16 16:13:45 UTC 2024
>
> Modified Files:
> src/distrib/amd64/liveimage/emuimage: Makefile rc.conf.emuimage
> spec.emuimage
>
> Log Message:
> restore amd64 live image support for resize root after
> And also slightly related: we need a way to mark directories as
> optional in the mtree files (or have a way to provide several
> alternative options). Typical issue: /var/shm is a symlink on most
> of my smaller machines, but it is impossible to make such setups pass
> the mtree tests.
Maybe
On Thu, Apr 11, 2024 at 01:06:10PM +, Taylor R Campbell wrote:
> I agree, this is related to the subject of, and could probably use the
> same mechanism as, PR 57581: set lists should have a way to obsolete
> shlibs in DESTDIR but not in postinstall.
>
> https://gnats.NetBSD.org/57581
And
> Date: Thu, 11 Apr 2024 11:19:38 +0700
> From: Robert Elz
>
> This is why I'd like to add a new keyword in the sets lists, like
> "obsolete" is - probably "optional" to mark files that aren't installed
> by the build, but might exist, and should simply be ignored if
> found - it isn't an error
Hi,
Periodic snapshot build fails for (probably) all platforms with
MKCOMPAT enabled:
http://releng.netbsd.org/builds/HEAD/202404101150Z/
Please take a look. And more importantly, careful tests are
always appreciated before commit. To be fair, there are tons of
combinations of mk.conf
Date:Thu, 11 Apr 2024 02:15:39 +
From:"Taylor R Campbell"
Message-ID: <20240411021539.a3272f...@cvs.netbsd.org>
| However, this means that update builds need manual intervention to
| delete $DESTDIR/var/run/named or else checkflist will fail, so add a
|
On Mon, Apr 08, 2024 at 23:31:16 +0200, Roland Illig wrote:
> Am 08.04.2024 um 21:18 schrieb Valery Ushakov:
> > "=\017FIFTEEN\0"
> >
> > with its result a few lines below that has:
> >
> > BURST=0xf=FIFTEEN
>
> Thank you for explaining this example. I had a gut feeling that there
> would be
Am 08.04.2024 um 21:18 schrieb Valery Ushakov:
> "=\017FIFTEEN\0"
>
> with its result a few lines below that has:
>
> BURST=0xf=FIFTEEN
Thank you for explaining this example. I had a gut feeling that there
would be some hidden correlation between some octal/hexadecimal
combinations, but I
On Mon, Apr 08, 2024 at 20:21:07 +0200, Roland Illig wrote:
> I didn't eradicate _all_ hexadecimal examples, I just made each example
> use only one number base, not mix them both. There are both octal and
> hexadecimal examples in the manual page.
That's not what "prefer octal in examples"
Am 08.04.2024 um 03:24 schrieb Valery Ushakov:
> On Sun, Apr 07, 2024 at 14:28:27 +, Roland Illig wrote:
>
>> Log Message:
>> snprintb.3: clean up formatting and wording, prefer octal in examples
>>
>> Using hexadecimal character escapes requires separate string literals if
>> the description
Hi,
It's likely minor, but I believe these changes are enough to also
update the documentation date:
Index: ./src/sbin/ifconfig/ifconfig.8
-.Dd November 25, 2022
+.Dd April 8, 2024
Also "If the interface id a lagg(4) pseudo-interface" probably was
meant to be "If the interface is a lagg(4)..."
On Sun, Apr 07, 2024 at 14:28:27 +, Roland Illig wrote:
> Log Message:
> snprintb.3: clean up formatting and wording, prefer octal in examples
>
> Using hexadecimal character escapes requires separate string literals if
> the description starts with one of the letters A-F; octal character
>
In article <20240405085127.b998ef...@cvs.netbsd.org>,
Robert Elz wrote:
>Module Name: src
>Committed By: kre
>Date: Fri Apr 5 08:51:27 UTC 2024
>
>Modified Files:
> src/external: Makefile
> src/external/mit/libuv/lib: Makefile
>
>Log Message:
>Probable hack fix for
Date:Fri, 5 Apr 2024 08:51:27 +
From:"Robert Elz"
Message-ID: <20240405085127.b998ef...@cvs.netbsd.org>
Christos, this seems to fix the builds, but I doubt it is really
done correctly (and I don't just mean the overlong line I left in
src/external/Makefile which
On Sat, Mar 30, 2024 at 23:20:38 -0400, Christos Zoulas wrote:
> Restore the minimum build to install elfdefinitions.h. Provide a pre-built
> copy, since we don't have m4 available. Use pax to install it because
> using the Makefile needs more stuff available (nbsed) which we have not
> built
On Sun, Mar 24, 2024 at 21:21:39 +0200, Andrius V wrote:
> Can you a bit clarify the meaning of "8 space tabs"
This is what VT set up screen called "Set 8 Column Tabs", i.e. "set
one tab every eight columns, starting at column 9" which was the
default setting.
Hi,
Can you a bit clarify the meaning of "8 space tabs", since file is not
exactly following any completely defined pattern. Should I use tabs
before multiline comment text (*^I^I) and align
text between routine name and description, also remove all unnecessary
whitespace characters? Attached
On Sat, Mar 23, 2024 at 21:10:45 +, Andrius Varanavicius wrote:
> Modified Files:
> src/games/larn: io.c
>
> Log Message:
> Attempt to fix descriptions of the routines in the initial comment block.
Please, can you fix this to use 8 space tabs as the rest of the file
does, as can be
Am 14.03.2024 um 21:27 schrieb Robert Elz:
> Date:Thu, 14 Mar 2024 20:53:13 +0100
> From:Roland Illig
> Message-ID: <9c7513f7-97b5-4d3b-9d66-dce483af7...@gmx.de>
>
> | I don't think the flags '+' and '0' make sense for strings, that's why I
> | decided to preserve
Date:Thu, 14 Mar 2024 20:53:13 +0100
From:Roland Illig
Message-ID: <9c7513f7-97b5-4d3b-9d66-dce483af7...@gmx.de>
| I don't think the flags '+' and '0' make sense for strings, that's why I
| decided to preserve existing behavior.
But the change only affected
Am 14.03.2024 um 20:38 schrieb Robert Elz:
> Module Name: src
> Committed By: kre
> Date: Thu Mar 14 19:38:56 UTC 2024
>
> Modified Files:
> src/usr.bin/stat: stat.c
>
> Log Message:
> While the change in 1.51 certainly retained binary compat with
> what was in 1.50 (while silencing
Thanks, should take remember this for the future reference.
On Wed, Mar 13, 2024 at 8:59 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Mar 13 06:59:01 UTC 2024
>
> Modified Files:
> src/sys/arch/evbmips/evbmips: interrupt.c
>
> Log Message:
>
Hi,
"matthew green" writes:
> Module Name: src
> Committed By: mrg
> Date: Thu Feb 22 02:47:27 UTC 2024
>
> Modified Files:
> src/tools/gcc: Makefile
>
> Log Message:
> enable isl support for GCC 12.
I have HAVE_GCC=12 in my /etc/mk.conf.
I have gotten the following error.
In article <20240218223315.800aff...@cvs.netbsd.org>,
Thomas Klausner wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: wiz
>Date: Sun Feb 18 22:33:15 UTC 2024
>
>Modified Files:
> src/usr.bin/ftp: ftp_var.h
>
>Log Message:
>ftp: bump FTPBUFLEN from 4kB to 16kB
>
I made it return EPERM if they are different.
christos
> On Feb 3, 2024, at 3:58 PM, J. Hannken-Illjes wrote:
>
>> On 3. Feb 2024, at 19:45, Christos Zoulas wrote:
>>
>> Oh, I fixed GETARGS, but not UPDATE... How about now?
>
> What is the expected result if we update a cd9660 mount with
> On 3. Feb 2024, at 19:45, Christos Zoulas wrote:
>
> Oh, I fixed GETARGS, but not UPDATE... How about now?
What is the expected result if we update a cd9660 mount with different
uid/gid or masks?
If it is forbidden the "mp->mnt_flag & MNT_UPDATE" case, lines 306 .. 312
of cd9660_vfsops.c
Oh, I fixed GETARGS, but not UPDATE... How about now?
christos
> On Feb 3, 2024, at 12:48 PM, J. Hannken-Illjes wrote:
>
>> On 3. Feb 2024, at 18:38, Christos Zoulas wrote:
>>
>> Fixed, thanks.
>
> Not really, with "struct iso_args *args = data" you cannot set fields
> beyond "datalen" here
> On 3. Feb 2024, at 18:38, Christos Zoulas wrote:
>
> Fixed, thanks.
Not really, with "struct iso_args *args = data" you cannot set fields
beyond "datalen" here and the MNT_UPDATE case is still missing.
--
J. Hannken-Illjes - hann...@mailbox.org
Fixed, thanks.
christos
> On 2. Feb 2024, at 21:27, Christos Zoulas wrote:
>
> Module Name: src
> Committed By: christos
> Date: Fri Feb 2 20:27:26 UTC 2024
>
> Modified Files:
> src/sbin/mount_cd9660: Makefile mount_cd9660.8 mount_cd9660.c
> src/sys/fs/cd9660: cd9660_extern.h cd9660_mount.h cd9660_vfsops.c
>
"Taylor R Campbell" writes:
> Mark /var/run/named obsolete in the set lists. XXX This isn't quite
> right, because it is legitimate for /var/run/named to exist in a
> running installation, but it doesn't exist in a freshly installed
> system any more. Maybe we should just remove the entry from
On Thu, 25 Jan 2024 20:02:00 +0100, Roland Illig writes:
>>> Modified Files:
>>> src/usr.bin/make: make.1
>>>
>>> Log Message:
>>> Indicate that for :U newval is optional
>>
>> I think this is more confusing than helpful.
>
>I agree. Make doesn't distinguish between an empty string and an
On Thu, 25 Jan 2024 21:12:20 +0100, Roland Illig writes:
>them all. Due to this, I'd go with:
>
>> .It Cm \&:U\| Ns Ar newval
>> If the variable is undefined,
>> .Ar newval
>> (which may be empty) is the value.
That's almost exactly what I had in my 1st cut ;-)
Will do.
>Then, add the same
About optional arguments to modifiers, such as in ${VAR:U}:
Am 25.01.2024 um 20:54 schrieb Simon Gerraty:
> Is there perhaps a general statement somewhere (I may have missed it)
> that could cover all these and be cited to pedantic users?
> Eg to the effect of perhaps, unless stated otherwise
Am 25.01.2024 um 14:25 schrieb Valery Ushakov:
> On Thu, Jan 25, 2024 at 07:35:46 +, Simon J. Gerraty wrote:
>
>> Modified Files:
>> src/usr.bin/make: make.1
>>
>> Log Message:
>> Indicate that for :U newval is optional
>
> I think this is more confusing than helpful.
I agree. Make
In article <19118.1705868...@jacaranda.noi.kre.to>,
Robert Elz wrote:
>Date:Sun, 21 Jan 2024 18:16:28 - (UTC)
>From:chris...@astron.com (Christos Zoulas)
>Message-ID:
>
> | I think this is the yacc used by the build process, not the yacc
> | to build tools
On Sun, Jan 21, 2024 at 21:31:23 +, Roland Illig wrote:
> and also didn't make it clear that a few bits were omitted from
> having descriptions.
I dislike this part. It's internally inconsistent as it doesn't add
the placeholders for the low bits; and in many real-life scenarios
there will
Date:Sun, 21 Jan 2024 18:16:28 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| I think this is the yacc used by the build process, not the yacc
| to build tools with? I.e. will this yacc produce c files usable in
| the host compilation
Am 21.01.2024 um 19:16 schrieb Christos Zoulas:
> In article ,
> Valery Ushakov wrote:
>> On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote:
>>
>>> Consider providing parsedate(3) in libcompat, but then we'd need
>>> yacc...
>>
>> We already have yacc in tools - src/tools/yacc
>
> I
In article ,
Valery Ushakov wrote:
>On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote:
>
>> Consider providing parsedate(3) in libcompat, but then we'd need
>> yacc...
>
>We already have yacc in tools - src/tools/yacc
I think this is the yacc used by the build process, not the yacc
On Sun, Jan 21, 2024 at 11:55:56 -0500, Christos Zoulas wrote:
> Consider providing parsedate(3) in libcompat, but then we'd need
> yacc...
We already have yacc in tools - src/tools/yacc
-uwe
On Thu, Jan 18, 2024 at 06:43:21 +1100, matthew green wrote:
> > Log Message:
> > macppc: enable FFS_EI in GENERIC
> >
> > I'd say it should be enabled for anything with USB.
> >
> > ok macallan
>
> yay. i think we should enable it basically everywhere that it
> is not a space issue.
I think
> Log Message:
> macppc: enable FFS_EI in GENERIC
>
> I'd say it should be enabled for anything with USB.
>
> ok macallan
yay. i think we should enable it basically everywhere that it
is not a space issue. USB is just one common way, but i can
also modify or create my own images anyway, and
> No, that definitely wasn't intentional! I've just reverted
> that. Does that need a pullup for netbsd-10 ?
Thanks for your confirmation.
I have another fix to make GENERIC boot on my 3/60
(disable more several pseudo-devices to shrink binary)
so I'll handle a pullup request with your fix.
Hi Tsutsui,
Izumi Tsutsui wrote:
> simonb@ wrote:
>
> > cvs rdiff -u -r1.187 -r1.188 src/sys/arch/sun3/conf/GENERIC
>
> >> # Veriexec
> >> # include "dev/veriexec.config"
> >> +
> >> +no obmem0 at mainbus? # XX
>
> Is this intentional!?
No, that definitely wasn't
simonb@ wrote:
> Module Name: src
> Committed By: simonb
> Date: Sun Aug 7 02:52:30 UTC 2022
>
> Modified Files:
:
> src/sys/arch/sun3/conf: DISKLESS GENERIC GENERIC3X
:
> Log Message:
> UFS/LFS dirhash:
> - Enable UFS_DIRHASH if the architecture or kernel model specific config
In article <2017973.usquhbg...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Jan 2 19:27:57 UTC 2024
>>
>> Modified Files:
>> src/sys/sys:
I would also prefer current general "virt68k", rather than
specific emulators like qemu68k etc. because:
- it's unlikely that someone will design and implement new virtual
Ethernet/storage I/O devices for ancient architectures
- we should avoid dumb copies of MD locore.s, pmap_bootstrap.c,
> On Jan 3, 2024, at 9:16 AM, Jason Thorpe wrote:
>
> There’s really nothing Qemu specific about it, other than Qemu version number
> extraction.
Let me elaborate, actually, now that I am not constrained by thumbs-only typing.
It uses the generic Linux m68k “bootinfo”, which specify the
There’s really nothing Qemu specific about it, other than Qemu version number
extraction.
-- thorpej
Sent from my iPhone.
> On Jan 2, 2024, at 11:03 PM, Valery Ushakov wrote:
>
> On Wed, Jan 03, 2024 at 02:48:06 +, Jason R Thorpe wrote:
>
>> Add virt68k to MACHINES.m68k.
>
> "virt" is
On Wed, Jan 03, 2024 at 02:48:06 +, Jason R Thorpe wrote:
> Add virt68k to MACHINES.m68k.
"virt" is too generic a name, if this is specifically a qemu version,
may be it should have been called qemu68k... Guess it's too late now.
-uwe
Date:Tue, 2 Jan 2024 21:20:42 -0500
From:Jason Thorpe
Message-ID:
| seems safe
Safe probably, but also wrong. It looks to be there puerly
for the __BEGIN_DECLS / __END_DECLS definitions - which are
needed just beause has prototypes for lseek()
truncate() and
> On Jan 2, 2024, at 8:41 PM, Robert Elz wrote:
>
> I doubt that should really be including
> and almost certainly not , and shouldn't have prototypes
> for any functions at all.
seems safe — all of that stuff is in the implementation namespace.
-- thorpej
Date:Wed, 3 Jan 2024 03:15:39 +0300
From:Valery Ushakov
Message-ID:
| for userland uses should include stddef.h where size_t is supposed
| to come from
Unfortunately, while is defined to specify size_t it
isn't specified to include ssize_t - and many things
On Wed, Jan 03, 2024 at 01:06:57 +0100, Joerg Sonnenberger wrote:
> Date: Wed, 03 Jan 2024 01:06:57 +0100
> From: Joerg Sonnenberger
> Subject: Re: CVS commit: src/sys/sys
> To: source-changes-d@netbsd.org
>
> On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrot
On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Jan 2 19:27:57 UTC 2024
>
> Modified Files:
> src/sys/sys: rbtree.h
>
> Log Message:
> This uses size_t, so it always needs , remove ifdefs.
sys/types.h is
On Thu, Dec 28, 2023 at 11:08 PM Robert Elz wrote:
>
> [I could claim that the typo was deliberate, as part of
> the test but that would be kind of absurd, sh does
> no spell checking to test.]
>
> kre
>
Thanks for clarification. I definitely had few instances when I needed
to revert
Date:Thu, 28 Dec 2023 20:04:11 +
From:"Andrius Varanavicius"
Message-ID: <20231228200411.283ccf...@cvs.netbsd.org>
| Modified Files:
| src/tests/bin/sh: t_syntax.sh
| Log Message:
| s/synax/syntax/ in test description.
Thanks for the correction, but,
"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Tue Dec 19 07:05:36 UTC 2023
>
> Modified Files:
> src/sys/dev/usb: if_axen.c
>
> Log Message:
> Add support for AX88179A. From sc.dying on current-users.
>
>
> To generate a diff of this commit:
> cvs rdiff -u
Hi,
Will check and adjust. Thanks for the tip.
On Thu, Dec 14, 2023 at 2:12 AM Valery Ushakov wrote:
>
> On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote:
>
> > Module Name: src
> > Committed By: andvar
> > Date: Wed Dec 13 23:11:35 UTC 2023
> >
> > Modified Files:
>
On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote:
> Module Name: src
> Committed By: andvar
> Date: Wed Dec 13 23:11:35 UTC 2023
>
> Modified Files:
> src/sys/arch/sparc64/dev: vnet.c
> src/sys/arch/sparc64/sparc64: netbsd32_machdep_13.c
>
> Log Message:
>
Valery Ushakov wrote in
:
|On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote:
|
|> On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
|>
|>> While here, consistemntly use minus when minus is meant, rather that
|>> just using a hyphen.
|>
|> One has to be careful with
On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote:
> On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
>
> > While here, consistemntly use minus when minus is meant, rather that
> > just using a hyphen.
>
> One has to be careful with this.
And to have this on record for
On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
> While here, consistemntly use minus when minus is meant, rather that
> just using a hyphen.
One has to be careful with this. In the literal context (Ql, Li, etc)
the ascii minus-hyphen in the input is preserved as such. In other
On Sat, Nov 25, 2023 at 11:36:34 -0800, Alistair Crooks wrote:
> I find it better to have
>
> MAN+= bar.7
> MAN+= foo.7
>
> Since a grep for 'MAN.*foo' will produce meaningful results
Also good for diffs in the future, e.g.
MAN += f.3
-MAN += g.3
MAN += h.3
vs.
f.3 \
-g.3 \
On Fri, Nov 24, 2023 at 18:09 Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:
> > Date: Sat, 25 Nov 2023 02:05:25 +
> > From: Taylor R Campbell
> >
> > > Date: Sat, 25 Nov 2023 00:23:33 - (UTC)
> > > From: chris...@astron.com (Christos Zoulas)
> > >
> > > Yes,
> Date: Sat, 25 Nov 2023 02:05:25 +
> From: Taylor R Campbell
>
> > Date: Sat, 25 Nov 2023 00:23:33 - (UTC)
> > From: chris...@astron.com (Christos Zoulas)
> >
> > Yes, this is indeed a lot better. I prefer though:
> >
> > MAN+= \
> > bar.7 \
> > foo.7
> >
> > It is faster to parse,
> Date: Sat, 25 Nov 2023 00:23:33 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> Yes, this is indeed a lot better. I prefer though:
>
> MAN+= \
> bar.7 \
> foo.7
>
> It is faster to parse, involves less typing, whitespace is cleaner.
This one doesn't have the same pattern for
In article <20231123211614.011a1f...@cvs.netbsd.org>,
Taylor R Campbell wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: riastradh
>Date: Thu Nov 23 21:16:13 UTC 2023
>
>Modified Files:
> src/share/man/man7: Makefile
>
>Log Message:
>share/man/man7/Makefile: Split MAN on
On Wednesday, November 15, 2023 4:15:28 AM CET you wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Nov 15 03:15:28 UTC 2023
>
> Modified Files:
> src/lib/libc/ssp: Makefile.inc
> Added Files:
> src/lib/libc/ssp: ssp_redirect.c
>
> Log Message:
> provide
Thank you, I should pay attention to that.
On Wed, Oct 25, 2023 at 9:02 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Oct 25 06:02:14 UTC 2023
>
> Modified Files:
> src/sys/arch/mips/mips: kgdb_machdep.c
>
> Log Message:
> ->
>
>
> To
On 2023/10/18 17:25, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Oct 18 08:25:14 UTC 2023
Modified Files:
src/tests/sbin/ifconfig: t_capabilities.sh
Log Message:
ifconfig/t_capabilities: Skip unless run_unsafe is configured to yes
The test modifies
On 2023/10/12 14:50, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Oct 12 05:50:56 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/ixgbe: ixgbe.c
>
> Log Message:
> ixg(4): Don't print wrong error message about ixgbe_num_queues.
>
> Don't override
On 2023-10-15 17.06, Joerg Sonnenberger wrote:
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
Module Name:src
Committed By: oster
Date: Sun Oct 15 22:36:53 UTC 2023
Modified Files:
src/sys/dev/pci/igc: if_igc.c
Log Message:
Fix build of the MODULAR
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
> Module Name: src
> Committed By: oster
> Date: Sun Oct 15 22:36:53 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/igc: if_igc.c
>
> Log Message:
> Fix build of the MODULAR kernel, which explicitly excludes vlans.
> Date: Fri, 13 Oct 2023 19:03:35 +
> From: Andrew Doran
>
> On Thu, Oct 12, 2023 at 11:55:46AM +0200, J. Hannken-Illjes wrote:
> > This is not true for RUMP. Hero you added sleepq_remove() as
> > "sleepq_unsleep(l, true)". This will unlock l_mutex without changing.
> >
> > Just poking
> Minor changes to jemalloc100 (the old one that only vax etc currently uses).
thanks.
i'm still using this version on a bunch of modern machines.
new jemalloc was problematic for a few things for me a
number of years ago and i keep meaning to test again, but
for now i'm still mostly using this
On Thu, Oct 12, 2023 at 11:55:46AM +0200, J. Hannken-Illjes wrote:
> > On 10. Oct 2023, at 20:58, Andrew Doran wrote:
> >
> > On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
> >
> >>> cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
> >>
> >> -sleepq_unsleep(l,
> Date: Fri, 13 Oct 2023 17:52:07 +0900
> From: Rin Okuyama
>
> It would be really nice if we can find some systematical/reliable methods to
> figure out files that really depends on struct syncobj, e.g.. I tried
> ctfdump(1) to
> *.o for kernel modules, but I cannot extract information better
> Date: Tue, 10 Oct 2023 18:58:29 +
> From: Andrew Doran
>
> On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
>
> > > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
> >
> > -sleepq_unsleep(l, false);
> > +sleepq_remove(l->l_sleepq, l, true);
> > }
> >
On Thu, Oct 12, 2023 at 8:23 PM Taylor R Campbell
wrote:
>
> > Date: Thu, 12 Oct 2023 17:06:02 +0900
> > From: Rin Okuyama
> >
> > On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote:
> > >
> > > Module Name:src
> > > Committed By: ad
> > > Date: Wed Oct 4 20:39:35 UTC 2023
> >
> Date: Thu, 12 Oct 2023 17:06:02 +0900
> From: Rin Okuyama
>
> On Thu, Oct 5, 2023 at 5:39â¯AM Andrew Doran wrote:
> >
> > Module Name:src
> > Committed By: ad
> > Date: Wed Oct 4 20:39:35 UTC 2023
> >
> > Modified Files:
> > src/sys/kern: kern_rwlock.c
> On 10. Oct 2023, at 20:58, Andrew Doran wrote:
>
> On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
>
>>> cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
>>
>> -sleepq_unsleep(l, false);
>> +sleepq_remove(l->l_sleepq, l, true);
>>}
>> }
>>
Cool! Can I send a pull up request to netbsd-10?
I've not yet observed deadlocks since this was committed,
fortunately or unfortunately, although ;)
Thanks,
rin
On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote:
>
> Module Name:src
> Committed By: ad
> Date: Wed Oct 4 20:39:35
On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
> > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
>
> -sleepq_unsleep(l, false);
> +sleepq_remove(l->l_sleepq, l, true);
> }
>}
>mutex_spin_exit(lock);
>
> Looks like sleepq_remove() unlocks l->l_mutex
> On 8. Oct 2023, at 15:23, Andrew Doran wrote:
>
> Module Name: src
> Committed By: ad
> Date: Sun Oct 8 13:23:05 UTC 2023
>
> Modified Files:
> src/sys/kern: kern_condvar.c kern_sleepq.c kern_timeout.c
>kern_turnstile.c sys_lwp.c sys_select.c
> src/sys/rump/librump/rumpkern: sleepq.c
>
OK, it makes sense. I will revert the changes. Thanks for your explanations.
On Sun, Oct 8, 2023 at 12:49 PM matthew green wrote:
>
> > I was changing news68k specific code, thus wasn't treating them as
> > common. But I understand the point.
>
> there's a *LOT* of m68k code that is copied
> I was changing news68k specific code, thus wasn't treating them as
> common. But I understand the point.
there's a *LOT* of m68k code that is copied into all the ports
that is almost identical, and should really be shared, but it
not, and changes like can make this harder to share.
ie, while
On Sun, Oct 8, 2023 at 6:56 AM Izumi Tsutsui wrote:
>
> > In this case maybe I should remove all FPSP references (vectors.S,
> > locore.S, Makefile.news68k (MD_LIBS={FPSP})?
>
> IMO we don't have to keep strict consistencies or buildabilities of
> options but rather should consider readabilities
> In this case maybe I should remove all FPSP references (vectors.S,
> locore.S, Makefile.news68k (MD_LIBS={FPSP})?
IMO we don't have to keep strict consistencies or buildabilities of
options but rather should consider readabilities and maintainabilities.
- options FPSP in a config file is not
On Thu, Oct 05, 2023 at 12:15:23PM +0200, Martin Husemann wrote:
> On Thu, Oct 05, 2023 at 09:59:49AM +, Andrew Doran wrote:
> > Yes that makes sense and is what I plan to do after work today if nobody
> > beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel,
> > IMO.
>
On Thu, Oct 05, 2023 at 09:59:49AM +, Andrew Doran wrote:
> Yes that makes sense and is what I plan to do after work today if nobody
> beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel,
> IMO.
Hey, this is a tiny landisk kernel, do not bloat it :-)
Unfortunately it
Martin,
On Thu, Oct 05, 2023 at 11:42:03AM +0200, Martin Husemann wrote:
> On Thu, Oct 05, 2023 at 11:36:23AM +0200, Martin Husemann wrote:
> > No, I was confused by the #ifdef maze - it breaks the build for
> > non-MULTIPROCESSOR kernels only, and I am not actually sure what "use"
> > gcc sees
1 - 100 of 11235 matches
Mail list logo
