> Module Name: src
> Committed By: mlelstv
> Date: Mon Apr 25 15:12:07 UTC 2022
>
> Modified Files:
> src/sys/arch/x68k/stand/boot: conf.c
> src/sys/arch/x68k/stand/xxboot: Makefile.xxboot xx.c
>
> Log Message:
> libsa now needs ioctl to support media with large sectors.
On 2022/04/25 23:03, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Apr 25 14:03:15 UTC 2022
Modified Files:
src/sys/arch/amiga/stand/bootblock/elf2bb: chksum.c elf2bb.c
Log Message:
Use htobe{16,32}(9) instead of be{16,32}toh(9) where appropriate.
No
> On 16. Apr 2022, at 18:40, Andrius Varanavicius wrote:
>
> Module Name: src
> Committed By: andvar
> Date: Sat Apr 16 16:40:54 UTC 2022
>
> Modified Files:
> src/sys/dev/raidframe: rf_netbsdkintf.c
>
> Log Message:
> Fix mistake in error branch locking caused by previous
> On Mar 26, 2022, at 9:39 AM, Taylor R Campbell
> wrote:
>
> `C string' is ambiguous because there are also char arrays that
> function as strings but which are not guaranteed to be NUL-terminated,
> as strncpy is intended for.
A non-terminated char array is not a C-string. The term
> On Mar 26, 2022, at 9:09 AM, Warner Losh wrote:
>
> Since all the 'C' standards[*] use "null-terminated" and "null character",
> it's likely best to use that terminology because there is a source of truth
> for its definition in case of ambiguity or doubt.
Ah, but you're giving up the
On Sat, Mar 26, 2022 at 9:53 AM Roland Illig wrote:
> Am 24.03.2022 um 02:55 schrieb David H. Gutteridge:
> > Module Name: src
> > Committed By: gutteridge
> > Date: Thu Mar 24 01:55:15 UTC 2022
> >
> > Modified Files:
> > src/lib/libc/gen: popen.3
> >
> > Log Message:
> >
> Date: Sat, 26 Mar 2022 16:53:19 +0100
> From: Roland Illig
>
> The term "null-terminated string" is quite common when talking about C.
> In contrast, the word "nul" in "nul-terminated" always reminds me of
> the character abbreviation in ASCII, which has a narrower scope than C.
> I prefer
> On Mar 26, 2022, at 9:17 AM, Martin Husemann wrote:
> When talking about it I prefer "zero terminated", or C-string, in
> contrast to C++ std::string (which are objects) or Pascal strings
> (which have an explicit length at the beginning).
Yes, I also prefer the term “C-string"
-- thorpej
On Sat, Mar 26, 2022 at 04:53:19PM +0100, Roland Illig wrote:
> The term "null-terminated string" is quite common when talking about C.
NULL terminated lists/array are quite common, but NULL is a pointer and
the string is terminated by a 0 char (sometimes spelled as \0 in a string
literal, but
Am 24.03.2022 um 02:55 schrieb David H. Gutteridge:
Module Name:src
Committed By: gutteridge
Date: Thu Mar 24 01:55:15 UTC 2022
Modified Files:
src/lib/libc/gen: popen.3
Log Message:
popen.3: minor spelling, grammar, style, and xref tweaks
To generate a diff of this
In article <977b81a4-d330-6722-7ce4-cc4e61011...@gmx.de>,
Roland Illig wrote:
>Am 25.03.2022 um 22:25 schrieb Christos Zoulas:
>> In article <20220325183551.0f039f...@cvs.netbsd.org>,
>> Roland Illig wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:src
>>> Committed By: rillig
>>> Date:
Am 26.03.2022 um 00:50 schrieb Tobias Nygren:
On Sat, 26 Mar 2022 00:31:45 +0100
Roland Illig wrote:
localtime.c: add back storage class 'register'
This reduces the differences to the upstream code.
I don't know why you did that. It is as simple to sed -e 's/register //g'
in upstream when
On Sat, 26 Mar 2022 00:31:45 +0100
Roland Illig wrote:
> >> localtime.c: add back storage class 'register'
> >>
> >> This reduces the differences to the upstream code.
> >
> > I don't know why you did that. It is as simple to sed -e 's/register //g'
> > in upstream when you diff. Adding register
Am 25.03.2022 um 22:25 schrieb Christos Zoulas:
In article <20220325183551.0f039f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Fri Mar 25 18:35:50 UTC 2022
Modified Files:
src/lib/libc/time: localtime.c
Log Message:
In article ,
Roland Illig wrote:
>
>The mess with the indentation comes from upstream. In our copy it's a
>bit worth than upstream, but not much.
I've asked upstream to indent consistently in the past. It has not happened.
I try to minimize the diffs with upstream so that we can keep patching
In article <20220325183551.0f039f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 25 18:35:50 UTC 2022
>
>Modified Files:
> src/lib/libc/time: localtime.c
>
>Log Message:
>localtime.c: add back storage class
In article <20220325190016.15114f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 25 19:00:16 UTC 2022
>
>Modified Files:
> src/lib/libc/time: localtime.c
>
>Log Message:
>localtime.c: take indentation style from
Am 25.03.2022 um 13:59 schrieb Robert Elz:
Date:Thu, 24 Mar 2022 23:32:30 +0100
From:Roland Illig
Message-ID: <6bb00924-edaf-a4c8-348e-ba1304d57...@gmx.de>
| Someone should clean up this mess.
No, they probabky shouldn't, in general.
That source comes from
Date:Thu, 24 Mar 2022 23:32:30 +0100
From:Roland Illig
Message-ID: <6bb00924-edaf-a4c8-348e-ba1304d57...@gmx.de>
| Someone should clean up this mess.
No, they probabky shouldn't, in general.
That source comes from the tz project (currently from
tzcode2022a) with
Am 24.03.2022 um 17:15 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Thu Mar 24 16:15:05 UTC 2022
Modified Files:
src/lib/libc/time: localtime.c
Log Message:
put back the 2022a changes and fix the misplaced brace.
To generate a diff of this
On Wed, Mar 23, 2022 at 02:00:29PM +0100, Tobias Nygren wrote:
> I think this commit broke something.
> date(1) no longer reports a time zone and is stuck at GMT time:
>
> $ ls -l /etc/localtime
> lrwxr-xr-x 1 root wheel 36 Mar 22 08:47 /etc/localtime ->
> /usr/share/zoneinfo/Europe/Stockholm
On Tue, 22 Mar 2022 13:48:39 -0400
Christos Zoulas wrote:
> Modified Files:
> src/lib/libc/time: CONTRIBUTING Makefile NEWS localtime.c private.h
> theory.html tz-link.html tzselect.8 tzselect.ksh version zdump.c
> zic.c
>
> Log Message:
> welcome to tzcode-2022a
Hi,
Am 19.03.2022 um 16:28 schrieb Paul Goyette:
Does this impact PR/51084 at all?
PR/51084 is about MAKEVERBOSE as well, but it's a different part of the
build infrastructure. So no, that PR is not yet fixed.
Does this impact PR/51084 at all?
On Sat, 19 Mar 2022, Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Sat Mar 19 14:35:13 UTC 2022
Modified Files:
src: Makefile
Log Message:
Makefile: fix location of postinstall program for MAKEVERBOSE > 2
If
Am Fri, Mar 18, 2022 at 04:06:18PM + schrieb Reinoud Zandijk:
> Module Name: src
> Committed By: reinoud
> Date: Fri Mar 18 16:06:18 UTC 2022
>
> Modified Files:
> src/sys/fs/udf: ecma167-udf.h
>
> Log Message:
> Replace the variable field data[0] to data[1] to avoid undefined
> Log Message:
> old drm: Use getticks(), not hardclock_ticks.
>
> Should delete this code, no idea if it even still compiles.
it did last i tried, and it still worked on the r100/r200 systems
that new drm is still problematic with.
not objecting...
.mrg.
Hi Alex,
Alexander Nasonov wrote:
> Simon Burge wrote:
> > Why don't we just mount all the ZFS filesystems in mountcritlocal?
>
> Future versions may require loading of encryption keys over kerberos
> or a special pam module to decrypt /home/$USER.
How is this different to the existing "zfs
Greg Troxel writes:
[snip]
>
> I am opposed to deciding that all zfs filesystems should be treated as
> critical (in a world where we have not abolished the notion).
>
> We could have a discussion about why we even have the concept of
> critical filesystems, but if so that should not be
On Sat, 12 Mar 2022 08:26:01 +
Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Sat Mar 12 08:26:01 UTC 2022
>
> Modified Files:
> src/lib/libc/stdlib: hcreate.c
>
> Log Message:
> hcreate(3): use reallocarr instead of malloc(x * y)
Caution: malloc(0) and
Brad Spencer writes:
> What is referred to here is a specific ZFS idea and should not be
> confused with any sort of global notion. Specifically, ZFS, by default
> and in common use, does not use anything like a /etc/fstab or
> /etc/vfstab to specify where the filesets get mounted. It also
I apologize for failing to understand "zfs legacy mount" and incorrectly
associating it with how I usually encounter the word legacy.
I now understand that you meant to separate:
zfs's preferred path of having mountpoints stored as volume
properties, which is a different way of specifying
Greg Troxel writes:
[snip]
> [I don't really know what you mean by legacy (other than non-zfs, but
> you didn't say that, so perhaps you mean something different).]
[snip]
I am only going to speak to the use of "legacy" in this conversation.
What is referred to here is a specific ZFS idea
Simon Burge wrote:
> Why don't we just mount all the ZFS filesystems in mountcritlocal?
Future versions may require loading of encryption keys over kerberos
or a special pam module to decrypt /home/$USER.
Alex
Simon Burge writes:
> I'm running with a complete ZFS-only setup with no legacy mounts. This
> is my basic ZFS layout (leaving out a few mounts that don't add any more
> value to this discussion):
>
> NAME MOUNTPOINT
> pool0 /pool0
>
[ Oops, resending to include the source-changes-d list. ]
[ Sorry for the double-up for the original recipients. ]
Hi Alexander, folks,
Sorry for chiming in a bit late on this.
I'm running with a complete ZFS-only setup with no legacy mounts. This
is my basic ZFS layout (leaving out a few
Am 10.03.2022 um 22:48 schrieb David H. Gutteridge:
Module Name:src
Committed By: rillig
Date: Tue Mar 8 23:13:05 UTC 2022
Modified Files:
src/usr.bin/man: man.c
Log Message:
man: remove unused global variable 'instype' (since yesterday)
No functional change.
To
> Module Name:src
> Committed By: rillig
> Date: Tue Mar 8 23:13:05 UTC 2022
>
> Modified Files:
> src/usr.bin/man: man.c
>
> Log Message:
> man: remove unused global variable 'instype' (since yesterday)
>
> No functional change.
>
>
> To generate a diff of this
> Module Name: src
> Committed By: hgutch
> Date: Sun Mar 6 08:31:54 UTC 2022
>
> Modified Files:
> src/usr.sbin/makefs/ffs: buf.h newfs_extern.h
> Added Files:
> src/usr.sbin/makefs/ffs: namespace.h
>
> Log Message:
> Make sure daddr_t is a 64 bit type when building tools.
Am Tue, Mar 01, 2022 at 10:17:18AM +1100 schrieb matthew green:
> "Joerg Sonnenberger" writes:
> > Module Name:src
> > Committed By: joerg
> > Date: Mon Feb 28 16:30:10 UTC 2022
> >
> > Modified Files:
> > src/external/apache2/llvm: Makefile.inc
> >
> > Log Message:
"Joerg Sonnenberger" writes:
> Module Name: src
> Committed By: joerg
> Date: Mon Feb 28 16:30:10 UTC 2022
>
> Modified Files:
> src/external/apache2/llvm: Makefile.inc
>
> Log Message:
> When MKDEBUG is use, build LLVM with -g1 to significantly reduce debug
> information. This
"Roland Illig" writes:
> Module Name: src
> Committed By: rillig
> Date: Sun Feb 27 19:00:46 UTC 2022
>
> Modified Files:
> src/usr.bin/vmstat: vmstat.c
>
> Log Message:
> vmstat: unexport file-scope variable numdisks
>
> There is no need to make this variable externally visible.
Roland Illig writes:
> Am 09.02.2022 um 08:34 schrieb matthew green:
> > Module Name:src
> > Committed By: mrg
> > Date: Wed Feb 9 07:34:18 UTC 2022
> >
> > Modified Files:
> > src/usr.bin/vmstat: vmstat.c
> >
> > Log Message:
> > allow the number of disks
On Sun, Feb 27, 2022 at 11:50:15AM +0100, Martin Husemann wrote:
> On Sun, Feb 27, 2022 at 12:04:58AM +0100, Joerg Sonnenberger wrote:
> > Personally, I prefer the use of the C extension in cases like this. The
> > "portable" version is less readable...
>
> I would prefer the type correct C++
On Sun, Feb 27, 2022 at 12:04:58AM +0100, Joerg Sonnenberger wrote:
> Personally, I prefer the use of the C extension in cases like this. The
> "portable" version is less readable...
I would prefer the type correct C++ style variant (and making lint deal
with it, if it doesn't yet). At least gcc
Am Sat, Feb 26, 2022 at 03:04:40PM + schrieb Roland Illig:
> Module Name: src
> Committed By: rillig
> Date: Sat Feb 26 15:04:40 UTC 2022
>
> Modified Files:
> src/sys/dev/pci: if_wm.c
>
> Log Message:
> if_wm.c: fix value return from void function
>
> lint complained:
>
Am 09.02.2022 um 08:34 schrieb matthew green:
Module Name:src
Committed By: mrg
Date: Wed Feb 9 07:34:18 UTC 2022
Modified Files:
src/usr.bin/vmstat: vmstat.c
Log Message:
allow the number of disks displayed in the default output
to be controlled.
To generate a diff
On Sat, Feb 12, 2022, 11:52 AM Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:
> > Date: Sun, 13 Feb 2022 05:44:38 +1100
> > from: matthew green
> >
> > "Roland Illig" writes:
> > > Module Name:src
> > > Committed By: rillig
> > > Date: Fri Feb
Am 12.02.2022 um 20:10 schrieb Warner Losh:
I thought the rule was don't make purely whitespace changes UNLESS you
plan on making other changes to (or are fixing an oops you just made).
If that's the case, separate the two commits.
That sounds like a useful rule, I'll stick to it.
Roland
> Date: Sun, 13 Feb 2022 05:44:38 +1100
> from: matthew green
>
> "Roland Illig" writes:
> > Module Name:src
> > Committed By: rillig
> > Date: Fri Feb 11 21:36:46 UTC 2022
> >
> > Modified Files:
> > src/lib/libc/stdlib: getenv.c
> >
> > Log Message:
> >
"Roland Illig" writes:
> Module Name: src
> Committed By: rillig
> Date: Fri Feb 11 21:36:46 UTC 2022
>
> Modified Files:
> src/lib/libc/stdlib: getenv.c
>
> Log Message:
> libc/getenv: remove trailing whitespace
>
> No binary change.
please avoid purely whitespace changes unless
> Date: Fri, 11 Feb 2022 16:50:16 -0800
> From: Jason Thorpe
>
> > On Feb 11, 2022, at 9:53 AM, Taylor R Campbell wrote:
> >
> > That is, this was presumably meant to ensure (A) happens-before (B).
> > This relation is already guaranteed by ipi(9), so there is no need
> > for any explicit
> On Feb 11, 2022, at 9:53 AM, Taylor R Campbell wrote:
>
> That is, this was presumably meant to ensure (A) happens-before (B).
> This relation is already guaranteed by ipi(9), so there is no need
> for any explicit memory barrier.
Is this documented in ipi(9)?
-- thorpej
Taylor R Campbell wrote:
> > Date: Sat, 5 Feb 2022 21:21:53 +
> > From: Alexander Nasonov
> >
> > Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> > legacy mountpoints a try to see how much complexity they add.
>
> I use legacy mountpoints for / and /var, but it's a
> Date: Sat, 5 Feb 2022 21:21:53 +
> From: Alexander Nasonov
>
> Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> legacy mountpoints a try to see how much complexity they add.
I use legacy mountpoints for / and /var, but it's a little kludgey,
and from what I recall a
Alexander Nasonov writes:
> Brad Spencer wrote:
>> Alexander Nasonov writes:
>> > Are there any downside of mixing legacy and non-legacy mountpoints?
>> > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
>>
>> That should work fine as long as /var was arranged to be mounted
> Date: Sat, 5 Feb 2022 22:47:30 +0100
> From: Tobias Nygren
>
> On Sat, 5 Feb 2022 15:17:40 +
> Martin Husemann wrote:
>
> > Modified Files:
> > src/sys/kern: subr_autoconf.c
> >
> > Log Message:
> > cfdriver_iattr_count() is only used in a KASSERT, so #ifdef DIAGNOSTIC it.
>
> This
Date:Sat, 5 Feb 2022 22:20:16 +
From:David Brownlee
Message-ID:
| Oops, my earliest unix experience was on a BSD4.3 variant, so I was
| spoiled by ffs and didn't realise the (in this context) helpful v7fs
| behaviour with overlong filename components.
To
On Wed, 2 Feb 2022 at 17:24, Robert Elz wrote:
>
> Date:Wed, 2 Feb 2022 15:26:21 +
> From:David Brownlee
> Message-ID:
>
>
> | So, we just need an optional flag when mounting v7fs to truncate any
> | looked up filename component to 14 characters
>
> That's
On Sat, 5 Feb 2022 15:17:40 +
Martin Husemann wrote:
> Modified Files:
> src/sys/kern: subr_autoconf.c
>
> Log Message:
> cfdriver_iattr_count() is only used in a KASSERT, so #ifdef DIAGNOSTIC it.
This doesn't seem to work as intended.
In a kernel with "no options DIAGNOSTIC" I now
Brad Spencer wrote:
> Alexander Nasonov writes:
> > Are there any downside of mixing legacy and non-legacy mountpoints?
> > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
>
> That should work fine as long as /var was arranged to be mounted first.
> The other way around may
Alexander Nasonov writes:
> J. Hannken-Illjes wrote:
>> What is wrong with ZFS legacy mounts?
>>
>> $ zpool create -m legacy tank
>> $ zfs create tank/a
>> $ mount -t zfs tank/a /mnt
>
> Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't
> look into it because, well,
J. Hannken-Illjes wrote:
> What is wrong with ZFS legacy mounts?
>
> $ zpool create -m legacy tank
> $ zfs create tank/a
> $ mount -t zfs tank/a /mnt
Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't
look into it because, well, "legacy"...
Are there any downside of mixing
On Fri, Feb 04, 2022 at 10:19:03PM +, Alexander Nasonov wrote:
> These two "styles of mounting" are
>
> /sbin/mount /filesystem - looks up fs parameters in /etc/fstab
> /sbin/zfs mount dataset - looks up fs parameters in zpools
There are several things that could be done here. I would guess
> On 4. Feb 2022, at 23:19, Alexander Nasonov wrote:
>
> Martin Husemann wrote:
>> On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
>>> variable, it will mix two very different styles of mounting and
>>> compilate the code.
>
> s/compilate/complicate/
>
>> "different styles
Martin Husemann wrote:
> On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
> > variable, it will mix two very different styles of mounting and
> > compilate the code.
s/compilate/complicate/
> "different styles of mounting" sounds like a non-starter to me, maybe
> that should be
On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
> variable, it will mix two very different styles of mounting and
> compilate the code.
"different styles of mounting" sounds like a non-starter to me, maybe
that should be fixed first?
Martin
Hi Robert,
Robert Elz wrote:
> A couple of comments about your mount_critical_filesystems_zfs()
> function in rc.subr
Thank you for reviewing my code!
> It starts:
>
> eval _fslist=\$critical_filesystems_zfs
>
> I'm not sure what you're attempting to accomplish there.
I copied this
Alexander Nasonov wrote:
> Module Name: src
> Committed By: alnsn
> Date: Thu Feb 3 20:52:44 UTC 2022
>
> Modified Files:
> src/etc: rc.subr
>
> Log Message:
> Add mount_critical_filesystems_zfs
>
> The new function is similar to mount_critical_filesystems
> but it walks through
A couple of comments about your mount_critical_filesystems_zfs()
function in rc.subr
It starts:
eval _fslist=\$critical_filesystems_zfs
I'm not sure what you're attempting to accomplish there. The eval
command sees
fslist=$critical_filesystems_zfs
(the \ having quoted the '$'
Date:Wed, 2 Feb 2022 15:26:21 +
From:David Brownlee
Message-ID:
| So, we just need an optional flag when mounting v7fs to truncate any
| looked up filename component to 14 characters
That's not, or shouldn't be, necessary - that always happened, the limit
> On Feb 2, 2022, at 6:47 AM, Robert Elz wrote:
>
>Date:Wed, 2 Feb 2022 07:11:45 +
>From:David Holland
>Message-ID:
>
> | v7fs isn't a compat interface for old users,
>
> That's sad, I could do with something just for me!
>
> | it's a compat interface
Hello,
On Wed, 02 Feb 2022 21:47:25 +0700
Robert Elz wrote:
> So maybe it is for us truly old fogies (can we have v6fs as well?
Well, there is this thing...
https://github.com/jaylogue/retro-fuse
A user-space filesystem (FUSE) for accessing ancient Unix filesystems.
retro-fuse provides a way
On Wed, 2 Feb 2022 at 14:47, Robert Elz wrote:
>
> Date:Wed, 2 Feb 2022 07:11:45 +
> From:David Holland
> Message-ID:
>
> | v7fs isn't a compat interface for old users,
>
> That's sad, I could do with something just for me!
Sounds like we need a compat_kre(8)
Date:Wed, 2 Feb 2022 07:11:45 +
From:David Holland
Message-ID:
| v7fs isn't a compat interface for old users,
That's sad, I could do with something just for me!
| it's a compat interface for old disk images :-)
And makefs -t v7fs fits into that purpose
On Wed, Feb 02, 2022 at 05:43:45AM +0700, Robert Elz wrote:
> | Test mkdir(2) with one or more trailing slashes - this currently fails
> | for v7fs.
>
> As it should I think, trailing slashes are not simply deleted in v7fs.
>
> [...]
>
> If this was ever changed, it would not truly
Date:Tue, 1 Feb 2022 18:27:24 +
From:"Martin Husemann"
Message-ID: <20220201182724.90f82f...@cvs.netbsd.org>
| Test mkdir(2) with one or more trailing slashes - this currently fails
| for v7fs.
As it should I think, trailing slashes are not simply deleted in
> On Jan 30, 2022, at 2:41 PM, Roland Illig wrote:
>
> Am 30.01.2022 um 14:21 schrieb Christos Zoulas:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Jan 30 13:21:09 UTC 2022
>>
>> Modified Files:
>> src/usr.bin/make: dir.c job.c make.h
>>
>> Log
Am 30.01.2022 um 20:54 schrieb Christos Zoulas:
On Jan 30, 2022, at 2:41 PM, Roland Illig mailto:roland.il...@gmx.de>> wrote:
Am 30.01.2022 um 14:21 schrieb Christos Zoulas:
Module Name:src
Committed By:christos
Date:Sun Jan 30 13:21:09 UTC 2022
Modified Files:
src/usr.bin/make: dir.c job.c
On Sun, 30 Jan 2022 14:54:25 -0500, Christos Zoulas writes:
>> Since usr.bin/make is also used in tools/make, it needs to follow the
>> rules in tools/README, which say that all tools should stick to C89.
>> The format specifier %zu comes from C99 though.
>
>Yes, %zu is annoying because windows
Am 30.01.2022 um 14:21 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Sun Jan 30 13:21:09 UTC 2022
Modified Files:
src/usr.bin/make: dir.c job.c make.h
Log Message:
Make the GNode lineno unsigned to fix lint warning in var.c calling
On Tue, Jan 25, 2022 at 03:23:05AM +, Brett Lymn wrote:
> Module Name: src
> Committed By: blymn
> Date: Tue Jan 25 03:23:05 UTC 2022
>
> Modified Files:
> src/tests/lib/libcurses: debug_test t_curses.sh
> src/tests/lib/libcurses/check_files: add_wch3.chk get_wstr.chk
>
Should fix PR 56650
> Module Name: src
> Committed By: macallan
> Date: Fri Jan 21 21:00:26 UTC 2022
>
> Modified Files:
> src/sys/dev/fdt: fdt_port.c
>
> Log Message:
> when enumerating ports and endpoints treat missing 'reg' properties as zero
> ok jmcneill:
> Looking at Linux.
On 22-01-16 12:11, rudolf wrote:
| On 1/9/22 4:33 AM, Luke Mewburn wrote:
| > Module Name: src
| > Committed By: lukem
| > Date: Sun Jan 9 03:33:26 UTC 2022
| >
| > Modified Files:
| > src/usr.sbin/etcupdate: etcupdate etcupdate.8
| >
| > Log Message:
On 1/9/22 4:33 AM, Luke Mewburn wrote:
Module Name:src
Committed By: lukem
Date: Sun Jan 9 03:33:26 UTC 2022
Modified Files:
src/usr.sbin/etcupdate: etcupdate etcupdate.8
Log Message:
etcupdate: add -? for help. improve option errors
Support -? to show help.
On Sun, Jan 16, 2022 at 01:13:04PM +0100, Roland Illig wrote:
> I'm not sure what the perfect commit message would look like that
> would keep us both unsurprised and how much time we should spend
> discussing about this particular case since the code itself can be
> reviewed in a few seconds.
16.01.2022 12:44:02 Valery Ushakov :
> On Sun, Jan 16, 2022 at 10:30:45 +, Roland Illig wrote:
>
>> Modified Files:
>> src/lib/libcurses: addbytes.c ins_wstr.c
>>
>> Log Message:
>> libcurses: remove unreachable statements
>
> That summary sounds kinda misleading to me. It's
On Sun, Jan 16, 2022 at 10:30:45 +, Roland Illig wrote:
> Modified Files:
> src/lib/libcurses: addbytes.c ins_wstr.c
>
> Log Message:
> libcurses: remove unreachable statements
That summary sounds kinda misleading to me. It's technically true -
the commit removes unreachable *empty*
Am 09.01.2022 um 23:04 schrieb Joerg Sonnenberger:
On Fri, Jan 07, 2022 at 08:04:49PM +, Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Fri Jan 7 20:04:49 UTC 2022
Modified Files:
src/usr.bin/make: for.c
Log Message:
make: use simpler code for
On Fri, Jan 07, 2022 at 08:04:49PM +, Roland Illig wrote:
> Module Name: src
> Committed By: rillig
> Date: Fri Jan 7 20:04:49 UTC 2022
>
> Modified Files:
> src/usr.bin/make: for.c
>
> Log Message:
> make: use simpler code for handling .for loops
This seems backwards to me.
On Sun, Jan 09, 2022 at 01:18:32AM +0100, Roland Illig wrote:
> If I were to extract the newly added code into a function call
> cpp_skip_string(, varname), would that help? That function could be
> used in var.c as well, for example in ModMatch and ModMatchEq.
Yes, it should be a utility
Am 08.01.2022 um 23:54 schrieb nia:
On Fri, Jan 07, 2022 at 08:04:49PM +, Roland Illig wrote:
Using memcmp for comparing the variable name was probably overkill since
the variable names are usually very short, so rather compare them byte
by byte.
I don't see the point of this change - it
On Fri, Jan 07, 2022 at 08:04:49PM +, Roland Illig wrote:
> Using memcmp for comparing the variable name was probably overkill since
> the variable names are usually very short, so rather compare them byte
> by byte.
I don't see the point of this change - it makes the code harder to
read. We
On Thu, Jan 06, 2022 at 06:18:13 +, Brett Lymn wrote:
> Module Name: src
> Committed By: blymn
> Date: Thu Jan 6 06:18:13 UTC 2022
>
> Modified Files:
> src/lib/libcurses: slk.c
>
> Log Message:
> Properly size and array to hold the larget return from wctomb.
I'm not sure
In article <20220105014628.9f952f...@cvs.netbsd.org>,
Robert Elz wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kre
>Date: Wed Jan 5 01:46:28 UTC 2022
>
>Modified Files:
> src/etc: Makefile
>
>Log Message:
>Install the missing sh syntax element in the MKDEBUGKERNEL = no
> Modified Files:
> src/sys/conf: copyright
>
> Log Message:
> Welcome to 2022!
Please don't forget pullup requests for release branches.
(looks 2021 was missed in 9.2)
---
Izumi Tsutsui
> - We only make a debuginstall rule to install netbsd-${KERNEL_CONFIG}.debug
> if MKDEBUG=yes
this part pollutes my $DESTDIR with non-distrib kernel info still,
which also means it requires a $DESTDIR to build a kernel now.
i think that we should not do this in the kernel build but inside
the
Hi,
Tobias Nygren writes:
> On Fri, 31 Dec 2021 01:44:19 +0900
> Ryo ONODERA wrote:
>
>> # link LOCKDEBUG/netbsd
>> /usr/world/9.99/amd64/tools/bin/x86_64--netbsd-ld -Map netbsd.map --cref -T
>> netbsd.ldscript -Ttext 0x8020 -e start -z max-page-size=0x20
>> -X -o
Hi,
chris...@astron.com (Christos Zoulas) writes:
> In article <875yr6ujoc@brownie.elements.tetera.org>,
> Ryo ONODERA wrote:
>
>>My Makefile for the kernel has the following line.
>>Your code may expect BUILD_KERNEL as kernel configuration file name,
>>for example GENERIC or LOCKDEBUG in
On Fri, 31 Dec 2021 01:44:19 +0900
Ryo ONODERA wrote:
> # link LOCKDEBUG/netbsd
> /usr/world/9.99/amd64/tools/bin/x86_64--netbsd-ld -Map netbsd.map --cref -T
> netbsd.ldscript -Ttext 0x8020 -e start -z max-page-size=0x20
> -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o}
Hi,
In MKDEBUG=yes and MKDEBUG=no cases,
./build.sh kernel=LOCKDEBUG fails as follows, for example:
(snip)
# link LOCKDEBUG/netbsd
/usr/world/9.99/amd64/tools/bin/x86_64--netbsd-ld -Map netbsd.map --cref -T
netbsd.ldscript -Ttext 0x8020 -e start -z max-page-size=0x20 -X
501 - 600 of 11248 matches
Mail list logo
