CVS commit: src/usr.sbin/vnconfig

Module Name:src Committed By: gdt Date: Sat Oct 21 23:42:03 UTC 2023 Modified Files: src/usr.sbin/vnconfig: vnconfig.8 Log Message: vnconfig.8: Don't mention ciphertext After all, this is not cgd(4). To generate a diff of this commit: cvs rdiff -u -r1.49 -r1.50

CVS commit: src/usr.sbin/vnconfig

Module Name:src Committed By: gdt Date: Sat Oct 21 23:42:03 UTC 2023 Modified Files: src/usr.sbin/vnconfig: vnconfig.8 Log Message: vnconfig.8: Don't mention ciphertext After all, this is not cgd(4). To generate a diff of this commit: cvs rdiff -u -r1.49 -r1.50

CVS commit: src/usr.sbin/vnconfig

Module Name:src Committed By: gdt Date: Sat Oct 21 23:38:26 UTC 2023 Modified Files: src/usr.sbin/vnconfig: vnconfig.8 Log Message: vnconfig: Improve recent caching edit to man page Explain that typical usage patterns don't run into consistency issues. Xref the -i flag.

CVS commit: src/usr.sbin/vnconfig

Module Name:src Committed By: gdt Date: Sat Oct 21 23:38:26 UTC 2023 Modified Files: src/usr.sbin/vnconfig: vnconfig.8 Log Message: vnconfig: Improve recent caching edit to man page Explain that typical usage patterns don't run into consistency issues. Xref the -i flag.

CVS commit: src/usr.sbin/vnconfig

Module Name:src Committed By: gdt Date: Fri Oct 20 12:45:17 UTC 2023 Modified Files: src/usr.sbin/vnconfig: vnconfig.8 Log Message: vnconfig: Add caution to man page about cache bypassing behavior To generate a diff of this commit: cvs rdiff -u -r1.46 -r1.47

CVS commit: src/usr.sbin/vnconfig

Module Name:src Committed By: gdt Date: Fri Oct 20 12:45:17 UTC 2023 Modified Files: src/usr.sbin/vnconfig: vnconfig.8 Log Message: vnconfig: Add caution to man page about cache bypassing behavior To generate a diff of this commit: cvs rdiff -u -r1.46 -r1.47

CVS commit: src/distrib/amd64/installimage

Module Name:src Committed By: gdt Date: Mon Aug 14 13:54:05 UTC 2023 Modified Files: src/distrib/amd64/installimage: installimage.mk Log Message: amd64 installimage: Reduce non-xz size slightly to fit 4GB flash drives The installimage sizes were bumped in 2022 because of

CVS commit: src/distrib/amd64/installimage

Module Name:src Committed By: gdt Date: Mon Aug 14 13:54:05 UTC 2023 Modified Files: src/distrib/amd64/installimage: installimage.mk Log Message: amd64 installimage: Reduce non-xz size slightly to fit 4GB flash drives The installimage sizes were bumped in 2022 because of

CVS commit: src/share/man/man4

Module Name:src Committed By: gdt Date: Sat Jul 29 23:11:51 UTC 2023 Modified Files: src/share/man/man4: nvmm.4 Log Message: nvmm(4): Document that VMX Unrestricted Guest is required To generate a diff of this commit: cvs rdiff -u -r1.6 -r1.7 src/share/man/man4/nvmm.4

CVS commit: src/share/man/man4

Module Name:src Committed By: gdt Date: Sat Jul 29 23:11:51 UTC 2023 Modified Files: src/share/man/man4: nvmm.4 Log Message: nvmm(4): Document that VMX Unrestricted Guest is required To generate a diff of this commit: cvs rdiff -u -r1.6 -r1.7 src/share/man/man4/nvmm.4

Re: CVS commit: src/sbin/newfs

Taylor R Campbell writes: > Well, what happened is: > > 1. I was drafting posix_memalign and aligned_alloc for libbsdmalloc in >response to the thread about static program size yesterday, and >carefully reading the specs -- POSIX 2018, C11 -- to make sure I >got all the details

Re: CVS commit: src/sys/arch/i386/stand/bootxx

Emmanuel Dreyfus writes: > On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote: >> > Primary bootstrap is now able to read a GPT inside RAIDframe. >> did you also update documentation? > > We do not have any documentation specific to primary bootstrap. > x86/b

Re: CVS commit: src/sys/arch/i386/stand/bootxx

"Emmanuel Dreyfus" writes: > Log Message: > Primary bootstrap is now able to read a GPT inside RAIDframe. did you also update documentation?

Re: CVS commit: src/usr.bin/chflags

Taylor R Campbell writes: > jschauma@'s change did help clarify (1) and (2). Let's try to work > together to make it better? Well said. I can shed a little light on some of the questions. > 1. What is `arch' or `archived' supposed to mean? Who sets it, who >pays attention to it, and

Re: CVS commit: src/usr.bin/chflags

Valery Ushakov writes: > On Thu, May 25, 2023 at 07:17:52 -0400, Greg Troxel wrote: > >> Jan Schaumann writes: >> >> > Valery Ushakov wrote: >> >> On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote: >> > >> >> > Briefly

Re: CVS commit: src/usr.bin/chflags

Jan Schaumann writes: > Valery Ushakov wrote: >> On Wed, May 24, 2023 at 22:33:17 +, Jan Schaumann wrote: > >> > Briefly describe the 'arch' and 'nodump' flags. >> >> What makes them special and why is that these two have to be described >> here and not in chflags(2), where the flags are

Re: null-terminated vs. nul-terminated

"David H. Gutteridge" writes: Thanks for the history and it is all sensible. > "nul-terminated" and "null-terminated" seemed more common in man pages > that originated from historical BSD sources, so, lacking any style > guide, I inferred the lowercase "nul" was more "correct" as "BSD style"

Re: null-terminated vs. nul-terminated

Taylor R Campbell writes: >> 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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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

Re: CVS commit: src/etc

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 >

CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

Module Name:src Committed By: gdt Date: Thu Mar 25 18:41:29 UTC 2021 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_ioctl.c Log Message: zfs_ioctl.c: Drop WARNING that ZFS is under development Following discussions on current-users@, it seems many

CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

Module Name:src Committed By: gdt Date: Thu Mar 25 18:41:29 UTC 2021 Modified Files: src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_ioctl.c Log Message: zfs_ioctl.c: Drop WARNING that ZFS is under development Following discussions on current-users@, it seems many

Re: CVS commit: src/sys/arch/amd64/conf

matthew green writes: > could this be done with include and "no foo" statement? > eg, like sys/arch/sparc/conf/INSTALL does. Maybe, but I'm not sure it will end up working. Right now we don't know if any of the missing things will be trouble, and even if we do move to include/no I'd like to

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Fri Mar 5 20:30:56 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Approach GENERIC When processed to remove comments, blank lines, normalize whitespace, and sort/uniq (one line was previously

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Fri Mar 5 20:30:56 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Approach GENERIC When processed to remove comments, blank lines, normalize whitespace, and sort/uniq (one line was previously

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Fri Mar 5 20:18:39 UTC 2021 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: GENERIC: comment typo fix (spacing) To generate a diff of this commit: cvs rdiff -u -r1.585 -r1.586 src/sys/arch/amd64/conf/GENERIC Please

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Fri Mar 5 20:18:39 UTC 2021 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: GENERIC: comment typo fix (spacing) To generate a diff of this commit: cvs rdiff -u -r1.585 -r1.586 src/sys/arch/amd64/conf/GENERIC Please

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Thu Mar 4 19:01:41 UTC 2021 Modified Files: src/sys/arch/amd64/conf: std.xen Log Message: std.xen: Move towards std.amd64 (No functional change.) To generate a diff of this commit: cvs rdiff -u -r1.13 -r1.14

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Thu Mar 4 19:01:41 UTC 2021 Modified Files: src/sys/arch/amd64/conf: std.xen Log Message: std.xen: Move towards std.amd64 (No functional change.) To generate a diff of this commit: cvs rdiff -u -r1.13 -r1.14

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Thu Mar 4 16:02:11 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Move closer to GENERIC (NFC) This is another step in making XEN3_DOM0 closer to GENERIC. It is just reordering lines, adding

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Thu Mar 4 16:02:11 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Move closer to GENERIC (NFC) This is another step in making XEN3_DOM0 closer to GENERIC. It is just reordering lines, adding

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Thu Mar 4 15:58:50 UTC 2021 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: GENERIC: Tiny comment adjustment (NFC) While making XEN3_DOM0 more like GENERIC, I noticed a few differences where GENERIC was off --

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Thu Mar 4 15:58:50 UTC 2021 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: GENERIC: Tiny comment adjustment (NFC) While making XEN3_DOM0 more like GENERIC, I noticed a few differences where GENERIC was off --

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Wed Mar 3 12:31:19 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Move closer to GENERIC (NFC) This commit reorders some lines, and brings in commented lines from GENERIC to reduce the diff.

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Wed Mar 3 12:31:19 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Move closer to GENERIC (NFC) This commit reorders some lines, and brings in commented lines from GENERIC to reduce the diff.

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Tue Mar 2 18:10:31 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Fix pckbc console attachment logic Copy PCKBD_CNATTACH_MAY_FAIL lines from GENERIC to XEN3_DOM0. GENERIC defines

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Tue Mar 2 18:10:31 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Fix pckbc console attachment logic Copy PCKBD_CNATTACH_MAY_FAIL lines from GENERIC to XEN3_DOM0. GENERIC defines

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Tue Mar 2 18:06:12 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Sync VERBOSE with GENERIC Copy the *VERBOSE option block from GENERIC, and prune the scattered verbose options in XEN3_DOM0,

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Tue Mar 2 18:06:12 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: XEN3_DOM0: Sync VERBOSE with GENERIC Copy the *VERBOSE option block from GENERIC, and prune the scattered verbose options in XEN3_DOM0,

CVS commit: src/sys/dev/usb

Module Name:src Committed By: gdt Date: Tue Mar 2 00:18:22 UTC 2021 Modified Files: src/sys/dev/usb: ukbd.c Log Message: ukbd: GC some 20 year old code (NFC) Long ago, code was improved to allow detaching keyboards that were the console, but the old commen and panic()

CVS commit: src/sys/dev/usb

Module Name:src Committed By: gdt Date: Tue Mar 2 00:18:22 UTC 2021 Modified Files: src/sys/dev/usb: ukbd.c Log Message: ukbd: GC some 20 year old code (NFC) Long ago, code was improved to allow detaching keyboards that were the console, but the old commen and panic()

CVS commit: src/sys/dev/usb

Module Name:src Committed By: gdt Date: Tue Mar 2 00:01:27 UTC 2021 Modified Files: src/sys/dev/usb: ukbd.c Log Message: ukbd: Condition probe-time verbosity on USBVERBOSE Previously, this driver switched on more verbose messages based on DIAGNOSTIC. But, the messages

CVS commit: src/sys/dev/usb

Module Name:src Committed By: gdt Date: Tue Mar 2 00:01:27 UTC 2021 Modified Files: src/sys/dev/usb: ukbd.c Log Message: ukbd: Condition probe-time verbosity on USBVERBOSE Previously, this driver switched on more verbose messages based on DIAGNOSTIC. But, the messages

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Mon Mar 1 13:52:50 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: amd64/conf/XEN3_DOM0: Add comment This commit merely adds a comment explaining how XEN3_DOM0 ought to relate to GENERIC. To generate a

CVS commit: src/sys/arch/amd64/conf

Module Name:src Committed By: gdt Date: Mon Mar 1 13:52:50 UTC 2021 Modified Files: src/sys/arch/amd64/conf: XEN3_DOM0 Log Message: amd64/conf/XEN3_DOM0: Add comment This commit merely adds a comment explaining how XEN3_DOM0 ought to relate to GENERIC. To generate a

Re: CVS commit: src/tests/lib/libarchive

Jason Thorpe writes: >> On Jun 16, 2020, at 8:43 AM, Martin Husemann wrote: >> >> No, that is definitively not OK, which is what the PR is about. >> >> It is not OK for a regular atf run to cause a reboot of the test machine >> though, so this is a temporary hack around the issue (and

Re: CVS commit: src/external/gpl3

Great to hear of progress. I don't see why we don't care about 8. Given our release policy, that is supported until 10 is released.

Re: CVS commit: src/external/gpl3

Generally speaking divergence with upstream is a problem and we lost these changes anyway in pkgsrc and every standalone GNU toolchain copy. Agreed that divergence is a problem, but so is having bugs. It's a question of the right balance in each case. Finding a creative way to make this at

Re: CVS commit: src/external/gpl3

Greg Troxel writes: > It seem really obvious to me, and obvious that it is netbsd consensus, > that a tool that needs tmp (without needing persistence) should default > to /tmp. So I think it's unreasonable to follow upstream here, and > unreasonable to ask everybody to either

Re: CVS commit: src/external/gpl3

Kamil Rytarowski writes: > On 26.03.2020 15:01, Martin Husemann wrote: >> On Thu, Mar 26, 2020 at 02:57:40PM +0100, Kamil Rytarowski wrote: >>> The build of tools could be fixed independently. >> The problem is that we build the whole system with the tools gcc, and that >> gcc misbehaves (or so

Re: CVS commit: src/external/gpl3

Taylor R Campbell writes: >> Do we insist on this patch? Can we remove it from local sources? > > We should keep the change. There is no semantic justification for > putting build-time temporary files in the directory for temporary > files that are meant to persist across reboot. These

CVS commit: src

Module Name:src Committed By: gdt Date: Wed Mar 25 18:08:34 UTC 2020 Modified Files: src/lib/libc/sys: fdatasync.2 src/sys/kern: vfs_syscalls.c Log Message: Relax fdatasync restriction that fd be writable The restriction that a fd passed to fdatasync(2) must be

CVS commit: src

Module Name:src Committed By: gdt Date: Wed Mar 25 18:08:34 UTC 2020 Modified Files: src/lib/libc/sys: fdatasync.2 src/sys/kern: vfs_syscalls.c Log Message: Relax fdatasync restriction that fd be writable The restriction that a fd passed to fdatasync(2) must be

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

J. Hannken-Illjes writes: >> Forgot to add in the commit log, the changes have been pulled in from >> upstream openzfs. >> >> https://github.com/openzfs/zfs/commit/928e8ad47d3478a3d5d01f0dd6ae74a9371af65e#diff-9fd6b453f8153161abe0728c449e6505R4386 > > This is NOT our upstream -- This seems to

Re: CVS commit: src/sys/sys

Warner Losh writes: > Just a quick note: when FreeBSD when from 9 to 10, we had to play 'hunt the > wumpus' for all the autoconfig scripts that suddenly thought they were > configuring for FreeBSD 1.0. > > If you can arrange it, it might make sense to do a pkgsrc run on an > experimental system

Re: CVS commit: src/sys/sys

Martin Husemann writes: > On Mon, Dec 23, 2019 at 09:02:50AM -0500, Greg Troxel wrote: >> Well, we are coming up on a year since netbsd-9 was branched, or at >> least will arrive there before this discussion resolves. So cutting >> -10 before we hit 100 works for me :-)

Re: CVS commit: src/sys/sys

Kamil Rytarowski writes: > On 23.12.2019 01:54, Roy Marples wrote: >> On 22/12/2019 22:24, Andrew Doran wrote: >>> NetBSD 9.99.29 - struct mount changed. >> >> Just curious - does our build software cope with 3 digit for the last >> number? >> >> Roy > > At least from the __NetBSD_Version__

Re: CVS commit: src/share/mk

David Brownlee writes: > On Thu, 14 Nov 2019 at 21:05, Christos Zoulas wrote: >> >> The first issue is that I prefer to have tar respect existing >> symlinks (ones that it did not create by default -- without having >> to specify extra flags) since to do this (in my opinion) does not >> pose a

Re: CVS commit: src

m...@netbsd.org writes: > These seem to be lowercase versions of the same names. We're going to > have trouble with the people who use case insensitive filesystems and > CVS. With any luck the multicase stuff is just dups to prune and not useful. > (Or maybe it's not so bad because they're

Re: CVS commit: src/distrib/amd64/liveimage/emuimage

Martin Husemann writes: > On Thu, Aug 08, 2019 at 08:09:19PM -0400, Greg Troxel wrote: >> In addition, I don't like it that images have stuff in /boot in the DOS >> partition that can't be found in some obvious place, like /usr/mdec. >> But I haven't gotten around to trying

Re: CVS commit: src/distrib/amd64/liveimage/emuimage

Andreas Gustafsson writes: > I really don't like the general idea of introducing differences > between images and systems installed through sysinst. It's confusing > for users, and also means that testing of one is less likely to apply > to the other. Agreed strongly. In addition, I don't

CVS commit: src/etc

Module Name:src Committed By: gdt Date: Mon Jul 29 17:53:20 UTC 2019 Modified Files: src/etc: MAKEDEV.tmpl Log Message: MAKEDEV.tmpl: Create nodes for 16 USB hubs As proposed on current-users, but with better formatting. To generate a diff of this commit: cvs rdiff -u

CVS commit: src/etc

Module Name:src Committed By: gdt Date: Mon Jul 29 17:53:20 UTC 2019 Modified Files: src/etc: MAKEDEV.tmpl Log Message: MAKEDEV.tmpl: Create nodes for 16 USB hubs As proposed on current-users, but with better formatting. To generate a diff of this commit: cvs rdiff -u

CVS commit: src/sys/dev/ic

Module Name:src Committed By: gdt Date: Mon Jul 29 12:07:57 UTC 2019 Modified Files: src/sys/dev/ic: mfi.c Log Message: sys/dev/ic/mfi.c: Add missing break in switch (The entire switch is guarded by MFI_DEBUG and is known not to build.) Reported by Oskar. To generate a

CVS commit: src/sys/dev/ic

Module Name:src Committed By: gdt Date: Mon Jul 29 12:07:57 UTC 2019 Modified Files: src/sys/dev/ic: mfi.c Log Message: sys/dev/ic/mfi.c: Add missing break in switch (The entire switch is guarded by MFI_DEBUG and is known not to build.) Reported by Oskar. To generate a

Re: CVS commit: src

Thomas Klausner writes: > P.S.: The file is 44k, so I'm not convinced by the "/ is small" > argument. ;) 100 * 44k is 4400k :-) The / and /usr distinction is longstanding, I don't think we should give up on it easily.

Re: CVS commit: src/sys

Ryota Ozaki writes: >> And, if someone is inclined, having better checks with meaurable >> slowdown under DEBUG sounds ok too, but my revised understanding is >> unclear on whether that's helpful. (But I am only trying to keep >> performance under DIAGNOSTIC high; I am unconcerned about DEBUG

Re: CVS commit: src/sys

Ryota Ozaki writes: > On Tue, May 14, 2019 at 2:31 AM Jason Thorpe wrote: >> >> >> >> > On May 13, 2019, at 7:17 AM, Greg Troxel wrote: >> > >> > 2) Your option 2 seems to involve two things at once: >> > >> > - migrat

Re: CVS commit: src/sys

Ryota Ozaki writes: > On Sat, May 11, 2019 at 10:49 AM Greg Troxel wrote: >> >> I'm sorry for delaying this task. Finally I have benchmarked a revised >> >> patch >> >> (our benchmarking setups have been out of service for a couple of >> >

Re: CVS commit: src/sys

Kamil Rytarowski writes: > On 08.05.2019 11:34, Ryota Ozaki wrote: >> On Sat, Apr 20, 2019 at 6:45 PM Ryota Ozaki wrote: >>> >>> On Fri, Apr 19, 2019 at 6:49 PM Kamil Rytarowski wrote: On 19.04.2019 11:41, J. Hannken-Illjes wrote: >> On 19. Apr 2019, at 03:52, Ryota Ozaki wrote:

Re: CVS commit: src/etc

matthew green writes: > (i wouldn't pick 'wheel' as this group -- i would invent a > new group either called 'net' or 'wpa', with no underscore > since they're designed to be assigned, unlike the groups > for specific programs security models.) Are you saying that you are ok with the following:

Re: CVS commit: src/etc

Jason Thorpe writes: >> On Jan 13, 2019, at 5:21 AM, Greg Troxel wrote: >> >> Even if you have to be root, these changes are still hugely useful. >> "sudo wpa_cli" is not that hard, even if it seems like it should not be >> necessary. > > ...but

Re: CVS commit: src/etc

Roy Marples writes: > On 13/01/2019 10:20, matthew green wrote: >> shouldn't one need to be root to modify network configuration? >> i shouldn't be able to tell wpa_supplicant to do something as >> non-root, in a default install. > > In a default install the only member of wheel is root and >

Re: Unaligned access in kernel on ARMv6+ (Re: CVS commit: src/sys/dev/usb)

matthew green writes: >> In short, this is because -munaligned-access is enabled on ARMv6+ by >> default for GCC. As the unaligned memory access is forbidden in the >> supervisor mode unlike in the user mode, we need to explicitly specify >> -mno-unaligned-access for kernel on ARMv6+. > > i

Re: CVS commit: src/sys/arch/evbarm/conf

matthew green writes: > Nick Hudson writes: >> On 13/11/2018 08:21, matthew green wrote: >> >> Modified Files: >> >> src/sys/arch/evbarm/conf: std.generic64 >> >> >> >> Log Message: >> >> turn on MODULAR by default on aarch64 >> > >> > optional things should not be in "std.foo". that should

Re: CVS commit: src/etc/etc.evbarm

Greg Troxel writes: > "Herbert J. Skuhra" writes: > >> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote: >>> >>> Module Name:src >>> Committed By: skrll >>> Date: Sun Nov 4 21:41:12 UTC 20

Re: CVS commit: src/etc/etc.evbarm

"Herbert J. Skuhra" writes: > On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote: >> >> Module Name: src >> Committed By:skrll >> Date:Sun Nov 4 21:41:12 UTC 2018 >> >> Modified Files: >> src/etc/etc.evbarm: Makefile.inc >> >> Log Message: >> Only add

CVS commit: src/sys/arch/evbarm/conf

Module Name:src Committed By: gdt Date: Wed Jul 4 13:32:01 UTC 2018 Modified Files: src/sys/arch/evbarm/conf: RPI Log Message: RPI: remove commented-out pseudodevices Remove a number of commented out pseudodevice lines that are duplicative with GENERIC.common.

CVS commit: src/sys/arch/evbarm/conf

Module Name:src Committed By: gdt Date: Wed Jul 4 13:32:01 UTC 2018 Modified Files: src/sys/arch/evbarm/conf: RPI Log Message: RPI: remove commented-out pseudodevices Remove a number of commented out pseudodevice lines that are duplicative with GENERIC.common.

Re: CVS commit: src/external

m...@netbsd.org writes: > On Sun, Apr 08, 2018 at 04:57:07PM +, Jared D. McNeill wrote: >> @@ -82,6 +82,10 @@ The licenses currently used are: >> mpl Mozilla Public license. >> https://opensource.org/licenses/MPL-2.0 >> >> +nvidia-firmware NVIDIA

Re: CVS commit: src/sys

Manuel Bouyer writes: > On Mon, Oct 02, 2017 at 02:39:47PM +0200, Maxime Villard wrote: >> > Actually I did suggest to make the default dependant on MODULAR. >> >> what's the point exactly? > > that if I build a non-modular kernel with an emulation option explicitely >

Re: CVS commit: src/sys/dev/usb

Nick Hudson writes: > On 09/10/16 16:46, Jonathan A. Kollasch wrote: >> Module Name: src >> Committed By:jakllsch >> Date:Sat Sep 10 15:46:36 UTC 2016 >> >> Modified Files: >> src/sys/dev/usb: usbdevices.config >> >> Log Message: >> Make

CVS commit: src/sys/arch

Module Name:src Committed By: gdt Date: Sat Mar 19 23:21:03 UTC 2016 Modified Files: src/sys/arch/alpha/conf: GENERIC src/sys/arch/amd64/conf: GENERIC XEN3_DOM0 src/sys/arch/cats/conf: GENERIC src/sys/arch/evbarm/conf: HDL_G HPT5325 SHEEVAPLUG

Re: CVS commit: src/tests/lib/libutil

"David A. Holland" writes: > Module Name: src > Committed By: dholland > Date: Thu Dec 31 10:18:00 UTC 2015 > > Modified Files: > src/tests/lib/libutil: t_parsedate.c > > Log Message: > When evaluated on a Sunday, "next Sunday" means 7 days in the future, >

Re: CVS commit: src/sys/net

chris...@astron.com (Christos Zoulas) writes: > In article <20151210081103.e0fbbf...@cvs.netbsd.org>, > Kengo NAKAHARA wrote: >>-=-=-=-=-=- >> >>Module Name: src >>Committed By: knakahara >>Date: Thu Dec 10 08:11:03 UTC 2015 >> >>Modified Files: >>

CVS commit: src/external/gpl3

Module Name:src Committed By: gdt Date: Mon Nov 2 00:51:18 UTC 2015 Modified Files: src/external/gpl3/gcc.old/dist/gcc: Makefile.in src/external/gpl3/gcc/dist/gcc: Makefile.in Log Message: Use -f with cp. When the source tree is 444 (as should be unremarkable),

CVS commit: src/external/gpl3

Module Name:src Committed By: gdt Date: Mon Nov 2 00:51:18 UTC 2015 Modified Files: src/external/gpl3/gcc.old/dist/gcc: Makefile.in src/external/gpl3/gcc/dist/gcc: Makefile.in Log Message: Use -f with cp. When the source tree is 444 (as should be unremarkable),

Re: CVS commit: src/external/cddl/osnet/dist/lib/libdtrace/common

chris...@zoulas.com (Christos Zoulas) writes: > On Sep 25, 9:30am, m...@eterna.com.au (matthew green) wrote: > -- Subject: re: CVS commit: src/external/cddl/osnet/dist/lib/libdtrace/common > > | when you sync things, can you also include what version you sunc with? > | so for the next person to

Re: CVS commit: src/sys/dev

Michael van Elst mlel...@netbsd.org writes: Modified Files: src/sys/dev: dksubr.c Log Message: warn about labels only when built with DIAGNOSTIC This feels like an abuse of DIAGNOSTIC, which is supposed to be about asserts for detecting internal inconsistencies, not changing the

Re: CVS commit: src/distrib/atari/floppies/install

Izumi Tsutsui tsut...@ceres.dti.ne.jp writes: joerg@ wrote: Please don't commit untested and broken fix. Please file a PR instead if you can't test it. I agree with Christos that leaving the build broken is worse. The alternative band aids are much more involved, too. That shouldn't

Re: CVS commit: src/distrib/atari/floppies/install

Joerg Sonnenberger jo...@britannica.bec.de writes: On Sun, Apr 26, 2015 at 10:07:32AM -0400, Greg Troxel wrote: A broken build is evidence that the prior commits were not tested, and thus need fixing. Objecting to fixing the build without testing should be a far lower priority than

Re: CVS commit: src/share/misc

S.P.Zeidler s...@netbsd.org writes: Thus wrote Paul Goyette (p...@vps1.whooppee.com): At the very les, if we're going to have these acronyms, they should be listed in a separate file which is not searched by default. Similar to what is done with fortune(6). But that might not serve to

Re: CVS commit: src

Alan Barrett a...@cequrux.com writes: On Sat, 07 Mar 2015, Martin Husemann wrote: Anything that has no PCI. Could we rename LEGACY to something more descriptive? The problem with the name LEGACY is that it leaves people wondering whether or not particular hardware is old enough to be

Re: CVS commit: src

David Laight da...@l8s.co.uk writes: I'm also not sure we need a new kernel config. It seems the systems of interest are limited to 486 machines without PCI (and thus EISA probably), and that's a pretty narrow window around 1993-1994. So leaving the lines commented out with a comment

Re: CVS commit: src

Manuel Bouyer bou...@antioche.eu.org writes: On Sat, Mar 07, 2015 at 07:28:37AM +, matthew green wrote: Module Name: src Committed By:mrg Date:Sat Mar 7 07:28:37 UTC 2015 Modified Files: src/distrib/notes/i386: contents src/etc/etc.i386:

Re: CVS commit: src

Martin Husemann mar...@duskware.de writes: On Sat, Mar 07, 2015 at 08:13:17AM -0500, Greg Troxel wrote: Will LEGACY be built by default? I would vote no on that one. What's the set of computers that one has to use LEGACY on? Anything that has no PCI. That sounds ok, then. Is it just

Re: CVS commit: src/usr.bin/pwait

chris...@astron.com (Christos Zoulas) writes: If we want to make every single change to go through tech-userlevel, we should institute a rule to do so. To my knowledge we don't have yet such a rule. We already have the rest of the p* programs which originated in Solaris, we were missing this

Re: CVS commit: src/usr.bin/pwait

Marc Balmer m...@msys.ch writes: Am 03.03.15 um 14:35 schrieb Greg Troxel: chris...@astron.com (Christos Zoulas) writes: If we want to make every single change to go through tech-userlevel, we should institute a rule to do so. To my knowledge we don't have yet such a rule. We already

Re: CVS commit: src/usr.bin/pwait

Marc Balmer m...@msys.ch writes: I meant that adding to base was discuss-worthy because there's a bloat or necessary question, not because of risk of breakage. Sure. So how much bloat is pwait? Is it a huge piece of software or a small utility? I think that matters a bit. Posting a note

  1   2   3   >