Re: CVS commit: src/sys/sys
> 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
Re: CVS commit: src/share/mk
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 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
Re: CVS commit: src/share/mk
> 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 machine type and address of the various devices, and provisions for how reset/halt are handled are also dealt with generically. Every Linux m68k platform uses this mechanism and I would be shocked (SHOCKED) if some hypothetical future non-Qemu m68k VirtIO platform did not support Linux natively. The Qemu version extraction is actually done with one of those “bootinfo” records. There are really only two assumptions that are made: - RAM starts at PA $., the kernel starts with the MMU disabled, and is loaded at its link address. - I/O devices start at PA $FF00., and that they can be mapped VA==PA with a TT register. The latter would be pretty easy to deal with dynamically if the situation arose. And the former would be possible to adapt to if that assumption were to suddenly not be valid. Heck, the hp300 kernel is linked at VA=$. and knows how to deal with the start of RAM varying based on how much memory is installed (whereas the end of RAM is always at the same location, at the top of the physical address space. Weirdos.) -- thorpej
Re: CVS commit: src
> On May 19, 2024, at 3:25 PM, Christos Zoulas wrote: > > src/sys/compat/common: compat_110_mod.c sys_decrip_110.c > src/sys/compat/netbsd32: netbsd32_compat_110.c > src/sys/conf: compat_netbsd110.config > src/sys/modules/compat_110: Makefile > src/sys/modules/compat_netbsd32_110: Makefile Wait, why is there now a compat_110 module? netbsd-11 isn’t out yet. dup3() belongs in the compat_100 module. -- thorpej
Re: CVS commit: src
> On May 19, 2024, at 5:35 PM, Christos Zoulas wrote: > > In article <9c72736d-707b-4267-bd05-45bffea52...@me.com>, > Jason Thorpe wrote: >> >> >>> On May 19, 2024, at 3:25 PM, Christos Zoulas wrote: >>> >>> src/sys/compat/common: compat_110_mod.c sys_decrip_110.c >>> src/sys/compat/netbsd32: netbsd32_compat_110.c >>> src/sys/conf: compat_netbsd110.config >>> src/sys/modules/compat_110: Makefile >>> src/sys/modules/compat_netbsd32_110: Makefile >> >> Wait, why is there now a compat_110 module? netbsd-11 isn’t out yet. >> dup3() belongs in the compat_100 module. > > You asked for the syscall to be called dup3110 so I put it in compat_110... The new system call is dup3110 (“dup3 for 11.0”), the old one is “netbsd-10 compatibility”, so belongs in compat_10. -- thorpej
Re: CVS commit: src
> On May 19, 2024, at 6:21 PM, Christos Zoulas wrote: > > We discussed it with Taylor and decided to call it dup3100 after all since > we've > already followed the old scheme for kevent100 and it is better to be > consistent > for the 11 release.We can start calling new syscalls 12 after 11 is released. But how can the old one be in compat_11? -- thorpej
Re: CVS commit: src/sys
What issue is this change attempting to resolve? > On May 20, 2024, at 4:34 AM, Taylor R Campbell wrote: > > Module Name: src > Committed By: riastradh > Date: Mon May 20 11:34:19 UTC 2024 > > Modified Files: > src/sys/arch/sparc64/dev: pci_machdep.c > src/sys/arch/sparc64/include: pci_machdep.h > src/sys/arch/xen/include: pci_machdep.h > src/sys/arch/xen/xen: xpci_xenbus.c > src/sys/dev/acpi: acpi_mcfg.c > src/sys/dev/pci: pci.c pcivar.h > > Log Message: > pci: Pass cookie through pci_find_device, pci_enumerate_bus. > > New functions pci_find_device1 and pci_enumerate_bus1 have the cookie > argument. Existing symbols pci_find_device and pci_enumerate_bus are > now wrappers for the cookieless version. > > This drops the symbol pci_probe_device, in favour of a new > pci_probe_device1 with the cookie argument. But I don't think that > requires a revbump because it's only called by MD pci_enumerate_bus1 > implementations, which don't live in modules anyway. > > > To generate a diff of this commit: > cvs rdiff -u -r1.80 -r1.81 src/sys/arch/sparc64/dev/pci_machdep.c > cvs rdiff -u -r1.28 -r1.29 src/sys/arch/sparc64/include/pci_machdep.h > cvs rdiff -u -r1.21 -r1.22 src/sys/arch/xen/include/pci_machdep.h > cvs rdiff -u -r1.26 -r1.27 src/sys/arch/xen/xen/xpci_xenbus.c > cvs rdiff -u -r1.26 -r1.27 src/sys/dev/acpi/acpi_mcfg.c > cvs rdiff -u -r1.165 -r1.166 src/sys/dev/pci/pci.c > cvs rdiff -u -r1.117 -r1.118 src/sys/dev/pci/pcivar.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src
> On Sep 2, 2019, at 10:36 PM, Robert Elz wrote: > > I doubt that any of them really are truly > case insensitive ... rather than are insenstive to the case of ascii > chars, and that's usually it. APFS on macOS is truly case-insensitive, not just for ASCII. FWIW. -- thorpej
Re: CVS commit: src
> On Sep 3, 2019, at 5:04 AM, Sevan Janiyan wrote: > > On 03/09/2019 12:59, Brad Spencer wrote: >> One possible alternative to that is to install OpenZFS on MacOS and >> create a ZFS filesystem inside of whatever... > > Or a disk image which is case sensitive (hfs/apfs) problem is then that > it's slow. If your Mac has APFS, it's not quite that bad -- you can create a new file system that's case-insensitive inside the same APFS container as the file system with your home directory and space-share with that file system (the default behavior). You can do this all within Disk Utility without having to remember any command line magic. There is not a performance penalty for this. And the case-sensitive path is a well-tested, since that's what iOS uses. But there is definitely an annoyance penalty. It's an extra step (or two) that shouldn't be necessary. At least not without announcing the deprecation of support for case-insensitive host platforms, and providing a transition period for people rather than letting them be surprised (and then stuck) when they went to update their source tree. For Macs that aren't on APFS (I have an iMac at home in this situations that I build on all the time), they're just screwed by this change. Essentially, any Mac model that was not supported by macOS 10.14 is possibly stuck with HFS+ (this is because 10.13 only converted all-flash Macs to APFS; systems with HDDs remained on HFS+). While we're at it, are we going to say that pkgsrc is now case-sensitive-only, too? And if not, then why are we being lazy about src? -- thorpej
Re: Leak Sanitizer - how to suppress leaks
> On Sep 12, 2019, at 11:09 AM, Robert Elz wrote: > > To me it seems apparent that the sanatiser is detecting the local variable > in main() go out of scope when main() returns, and so the value it contains > (the pointer to the allocated memory) is lost, and so it is determined that > there is a leak. For any other function that would often be true, but for > main() it never is. It seems obvious that the sanitizer should special-case main(). -- thorpej
Re: CVS commit: src/sys/dev/ic
Should we make a PRIxxx macro for it? -- thorpej Sent from my iPhone. > On Sep 21, 2019, at 5:57 AM, Robert Elz wrote: > > Module Name:src > Committed By:kre > Date:Sat Sep 21 12:57:25 UTC 2019 > > Modified Files: >src/sys/dev/ic: mpt.c > > Log Message: > bus_addt_t is different widths on different archs, so there is no > one simple %?x format that will always work to print it. Cast to > intmax_t and use %jx which should work everywhere. > > > To generate a diff of this commit: > cvs rdiff -u -r1.19 -r1.20 src/sys/dev/ic/mpt.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/tests/fs/vfs
> 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 for old disk images :-) > > And makefs -t v7fs fits into that purpose how? > > So maybe it is for us truly old fogies (can we have v6fs as well? > Then I'd really feel at home.) Can I have a v7fs as root, and > boot from it? Does sysinst support it? I thought we maybe supported a system whose ROM boots from it? -- thorpej
Re: CVS commit: src/sys/kern
> 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
Re: null-terminated vs. nul-terminated (was: Re: CVS commit: src/lib/libc/gen)
> 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
Re: null-terminated vs. nul-terminated (was: Re: CVS commit: src/lib/libc/gen)
> 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 opportunity to use indirection to solve the problem. By calling it a "C-string", then those who care what the standard calls the terminating character can go look it up! :-) -- thorpej
Re: null-terminated vs. nul-terminated (was: Re: CVS commit: src/lib/libc/gen)
> 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 C-string is not ambiguous. This is something that, amazingly, even Internet trolls appear to agree on. However, they do disagree as to the spelling of the terminating character's name, which is why I think it's best to elide it altogether. -- thorpej
Re: CVS commit: src/share/misc
> On Mar 1, 2023, at 2:25 PM, Steffen Nurpmeso wrote: > > Jason R Thorpe wrote in > <20230301040454.c3b17f...@cvs.netbsd.org>: > |Module Name: src > |Committed By: thorpej > |Date: Wed Mar 1 04:04:54 UTC 2023 > | > |Modified Files: > | src/share/misc: acronyms.comp > | > |Log Message: > |Add NHACP (NABU HCCA Application Communication Protocol) > > NABU is Naturschutzbund Deutschland! > (Nature and Biodiversity Conservation Union Germany. > [Heck, they loose the Game!]) In this context, that’s not actually what it is, but it’s good to know there is at least one expansion :-) -- thorpej
Re: CVS commit: src/sbin/cgdconfig
> On Nov 27, 2021, at 6:01 PM, Christos Zoulas wrote: > > Module Name: src > Committed By: christos > Date: Sun Nov 28 02:01:30 UTC 2021 > > Modified Files: > src/sbin/cgdconfig: Makefile > > Log Message: > -lpthread to LDADD (fixes lint build) This change is wrong. The -pthread option to the compiler does more than just add -lpthread to the link phase. -- thorpej
Re: CVS commit: src/sbin/cgdconfig
> On Nov 28, 2021, at 8:05 AM, Christos Zoulas wrote: > > The change is correct; this is how it is done everywhere else in the tree. > You are right about -pthread doing more than adding -lpthread, but > in that case, the -pthread should be added to CFLAGS/COPTS etc, > not LDADD so that it is effective during the compilation phase too, > not just the link phase. When I made the change, I considered going > through the tree and adding -pthread to the CFLAGS/COPTS in the > Makefiles where -pthread is in LDADD, but I did not want to do a > half-assed job without thinking about it more: > > 1. which compilation flag should we add -pthread to? CFLAGS or > COPTS? What about c++? GCC defines some preprocessor macros in response to -pthread, so … CPPFLAGS? Perhaps a better choice is to have a USE_PTHREADS that individual program / library Makefiles can set to YES to cause the right magic to happen in bsd.sys.mk? > 2. do we remove the LDADD/DPADD pthread settings? I am thinking >perhaps not, it does not hurt, plus the DPADD will cause a rebuild >when libpthread changes. That could be hidden away by the above suggestion. -- thorpej
Re: CVS commit: src
It’s great to see this land, but “struct memfd” does not appear to be needed in . I would suggest moving it to sys_memfd.c. > On Jul 9, 2023, at 7:31 PM, Christos Zoulas wrote: > > Module Name: src > Committed By: christos > Date: Mon Jul 10 02:31:55 UTC 2023 > > Modified Files: > src/distrib/sets/lists/comp: mi > src/lib/libc/sys: Makefile.inc fcntl.2 > src/sys/compat/linux/arch/amd64: syscalls.master > src/sys/compat/linux/common: linux_fcntl.h linux_file.c linux_misc.c >linux_sysctl.c > src/sys/kern: sys_descrip.c vfs_syscalls.c vfs_vnops.c > src/sys/sys: fcntl.h file.h mman.h > src/usr.bin/fstat: fstat.c misc.c > Added Files: > src/lib/libc/sys: memfd_create.2 > src/sys/kern: sys_memfd.c > > Log Message: > Add memfd_create(2) from GSoC 2023 by Theodore Preduta > > > To generate a diff of this commit: > cvs rdiff -u -r1.2436 -r1.2437 src/distrib/sets/lists/comp/mi > cvs rdiff -u -r1.250 -r1.251 src/lib/libc/sys/Makefile.inc > cvs rdiff -u -r1.49 -r1.50 src/lib/libc/sys/fcntl.2 > cvs rdiff -u -r0 -r1.1 src/lib/libc/sys/memfd_create.2 > cvs rdiff -u -r1.67 -r1.68 src/sys/compat/linux/arch/amd64/syscalls.master > cvs rdiff -u -r1.20 -r1.21 src/sys/compat/linux/common/linux_fcntl.h > cvs rdiff -u -r1.122 -r1.123 src/sys/compat/linux/common/linux_file.c > cvs rdiff -u -r1.256 -r1.257 src/sys/compat/linux/common/linux_misc.c > cvs rdiff -u -r1.47 -r1.48 src/sys/compat/linux/common/linux_sysctl.c > cvs rdiff -u -r1.47 -r1.48 src/sys/kern/sys_descrip.c > cvs rdiff -u -r0 -r1.1 src/sys/kern/sys_memfd.c > cvs rdiff -u -r1.559 -r1.560 src/sys/kern/vfs_syscalls.c > cvs rdiff -u -r1.241 -r1.242 src/sys/kern/vfs_vnops.c > cvs rdiff -u -r1.54 -r1.55 src/sys/sys/fcntl.h > cvs rdiff -u -r1.92 -r1.93 src/sys/sys/file.h > cvs rdiff -u -r1.62 -r1.63 src/sys/sys/mman.h > cvs rdiff -u -r1.117 -r1.118 src/usr.bin/fstat/fstat.c > cvs rdiff -u -r1.24 -r1.25 src/usr.bin/fstat/misc.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src
> On Jul 30, 2023, at 7:46 AM, Tobias Nygren wrote: > Absence of this flag makes devel/libevent from pkgsrc fail to build -- > but should it really use epoll in the first place or should > we change it to prefer kqueue when both are available? The latter, I think! -- thorpej
Re: CVS commit: src/distrib/notes/sparc64
> On Sep 28, 2022, at 11:37 AM, Charlotte Koch wrote: > Maybe it makes sense to write an article in our own wiki instead? From > what I gather, reprogramming these NVRAM/clock chips is a *very* common > task. (In fact, I'm going to do it myself with the Sun Blade 100 that > I'm getting tomorrow!) Indeed, I think maintaining our own set of technical articles (citing other sources as appropriate, of course), would be a good thing. -- thorpej
Re: CVS commit: src/sys/external/bsd/drm2/drm
> On Jul 19, 2022, at 10:14 PM, matthew green wrote: > > looks like only a small number of files check for "alpha" > vs "__alpha__" currently, and all can likely be switched. Yah, and some I should just fix. -- thorpej
Re: CVS commit: src/sys/dev/ic
> On Aug 1, 2022, at 12:34 AM, Michael van Elst wrote: > > Module Name: src > Committed By: mlelstv > Date: Mon Aug 1 07:34:28 UTC 2022 > > Modified Files: > src/sys/dev/ic: ahcisata_core.c bcmgenet.c nslm7x.c nvmereg.h nvmevar.h >rtl8169.c tulip.c tulipreg.h > > Log Message: > Also fix shift values for SCT constants. ??? diff -u src/sys/dev/ic/tulip.c:1.205 src/sys/dev/ic/tulip.c:1.206 --- src/sys/dev/ic/tulip.c:1.205Sat Jun 25 02:46:15 2022 +++ src/sys/dev/ic/tulip.c Mon Aug 1 07:34:28 2022 @@ -1,4 +1,4 @@ -/* $NetBSD: tulip.c,v 1.205 2022/06/25 02:46:15 tsutsui Exp $ */ +/* $NetBSD: tulip.c,v 1.206 2022/08/01 07:34:28 mlelstv Exp $ */ /*- * Copyright (c) 1998, 1999, 2000, 2002 The NetBSD Foundation, Inc. @@ -36,7 +36,7 @@ */ #include -__KERNEL_RCSID(0, "$NetBSD: tulip.c,v 1.205 2022/06/25 02:46:15 tsutsui Exp $"); +__KERNEL_RCSID(0, "$NetBSD: tulip.c,v 1.206 2022/08/01 07:34:28 mlelstv Exp $"); #include @@ -4394,7 +4394,7 @@ */ /* XXX This should be auto-sense. */ - ifmedia_set(&mii->mii_media, IFM_ETHER | IFM_10_T); + ifmedia_set(&mii->mii_media, IFM_ETHER | IFM_10_5); tlp_print_media(sc); } > > > To generate a diff of this commit: > cvs rdiff -u -r1.105 -r1.106 src/sys/dev/ic/ahcisata_core.c > cvs rdiff -u -r1.11 -r1.12 src/sys/dev/ic/bcmgenet.c > cvs rdiff -u -r1.74 -r1.75 src/sys/dev/ic/nslm7x.c > cvs rdiff -u -r1.17 -r1.18 src/sys/dev/ic/nvmereg.h > cvs rdiff -u -r1.24 -r1.25 src/sys/dev/ic/nvmevar.h > cvs rdiff -u -r1.172 -r1.173 src/sys/dev/ic/rtl8169.c > cvs rdiff -u -r1.205 -r1.206 src/sys/dev/ic/tulip.c > cvs rdiff -u -r1.41 -r1.42 src/sys/dev/ic/tulipreg.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src/sys/dev/ic
Oops, never mind, I hadn't yet seen the follow-up revert. > On Aug 1, 2022, at 8:29 AM, Jason Thorpe wrote: > > > >> On Aug 1, 2022, at 12:34 AM, Michael van Elst wrote: >> >> Module Name: src >> Committed By: mlelstv >> Date: Mon Aug 1 07:34:28 UTC 2022 >> >> Modified Files: >> src/sys/dev/ic: ahcisata_core.c bcmgenet.c nslm7x.c nvmereg.h nvmevar.h >> rtl8169.c tulip.c tulipreg.h >> >> Log Message: >> Also fix shift values for SCT constants. > > ??? > > diff -u src/sys/dev/ic/tulip.c:1.205 src/sys/dev/ic/tulip.c:1.206 > --- src/sys/dev/ic/tulip.c:1.205Sat Jun 25 02:46:15 2022 > +++ src/sys/dev/ic/tulip.c Mon Aug 1 07:34:28 2022 > @@ -1,4 +1,4 @@ > -/* $NetBSD: tulip.c,v 1.205 2022/06/25 02:46:15 tsutsui Exp $ */ > +/* $NetBSD: tulip.c,v 1.206 2022/08/01 07:34:28 mlelstv Exp $ */ > > /*- > * Copyright (c) 1998, 1999, 2000, 2002 The NetBSD Foundation, Inc. > @@ -36,7 +36,7 @@ > */ > > #include > -__KERNEL_RCSID(0, "$NetBSD: tulip.c,v 1.205 2022/06/25 02:46:15 tsutsui Exp > $"); > +__KERNEL_RCSID(0, "$NetBSD: tulip.c,v 1.206 2022/08/01 07:34:28 mlelstv Exp > $"); > > > #include > @@ -4394,7 +4394,7 @@ > */ > >/* XXX This should be auto-sense. */ > - ifmedia_set(&mii->mii_media, IFM_ETHER | IFM_10_T); > + ifmedia_set(&mii->mii_media, IFM_ETHER | IFM_10_5); > >tlp_print_media(sc); > } > > >> >> >> To generate a diff of this commit: >> cvs rdiff -u -r1.105 -r1.106 src/sys/dev/ic/ahcisata_core.c >> cvs rdiff -u -r1.11 -r1.12 src/sys/dev/ic/bcmgenet.c >> cvs rdiff -u -r1.74 -r1.75 src/sys/dev/ic/nslm7x.c >> cvs rdiff -u -r1.17 -r1.18 src/sys/dev/ic/nvmereg.h >> cvs rdiff -u -r1.24 -r1.25 src/sys/dev/ic/nvmevar.h >> cvs rdiff -u -r1.172 -r1.173 src/sys/dev/ic/rtl8169.c >> cvs rdiff -u -r1.205 -r1.206 src/sys/dev/ic/tulip.c >> cvs rdiff -u -r1.41 -r1.42 src/sys/dev/ic/tulipreg.h >> >> Please note that diffs are not public domain; they are subject to the >> copyright notices on the relevant files. >> > > -- thorpej -- thorpej
Re: CVS commit: src
On Jul 20, 2009, at 10:30 AM, Christos Zoulas wrote: Log Message: bump libcrypto and friends; OpenSSL abi change: do_cipher last argument changed from u_int to size_t. Affects _LP64 only. ...only if the argument is in a slot that is not passed in a register. If it was passed in a register, it was already being promoted to register width. -- thorpej
Re: CVS commit: src
On Jul 21, 2009, at 1:28 PM, Christos Zoulas wrote: True, but why risk it? It's unnecessary to bump the library version, and bumping the library version is somewhat invasive / disruptive. Seems silly to do it unnecessarily. -- thorpej
Re: CVS commit: src/etc/rc.d
On Aug 3, 2009, at 10:45 AM, Perry E. Metzger wrote: Module Name:src Committed By: perry Date: Mon Aug 3 17:45:48 UTC 2009 Modified Files: src/etc/rc.d: named ntpdate Log Message: ntpdate can't work without named because a modern ntp.conf has dns names in it. We therefore now depend on it. However, this would have then created a circular dependency because named depended on "SERVERS", and racoon was before SERVERS and required kdc, and kdc needs the time to be right and thus depended on ntp. Instead, have named depend on NETWORKING (so that there is a network there), mountcritremote (so we know that named has a directory to work from) and syslogd (so that named has some place to spew information). I'm not sure this is perfect, but it is certainly a big improvement over constantly failing ntpdate runs during boot. Definitely not perfect .. named might also depend on ntp (by way of kdc) if GSS-TSIG is enabled. Explicit dependencies are the pits. Launch on demand is the way to go. -- thorpej
Re: CVS commit: src/sys/common/bus_dma
On Aug 21, 2009, at 12:16 AM, David Holland wrote: On Fri, Aug 21, 2009 at 03:33:17AM +, Jason R Thorpe wrote: Added Files: src/sys/common/bus_dma: bus_dmamem_common.c bus_dmamem_common.h Log Message: Add some common bus_dmamem routines to be shared by multiple platforms. Do these really need to be in their own private directory? (whose name, I might add, is confusing in the presence of src/common...) This is intended to be a collection of common routines for various subsystems to use. If we had real language / runtime support for it in the kernel, these would be common implementations of base classes instead. Because this will likely grow into a fairly large collection of miscellaneous stuff, I figured a separate area would be appropriate. sys/kern is way too cluttered as it is (and, IMO, also needs to be split up a bit, but I hesitate to do it until we have a decent version control system that can maintain history across moves). src/common is stuff shared between kernel and userland. -- thorpej
Re: CVS commit: src/sys/arch/pmax/include
On Aug 22, 2009, at 4:08 PM, Havard Eidnes wrote: Module Name:src Committed By: he Date: Sat Aug 22 23:08:01 UTC 2009 Modified Files: src/sys/arch/pmax/include: loadfile_machdep.h Log Message: Remove BOOT_AOUT, since our mips ports no longer deal with a.out. ...and never really did. This is not a big loss. To generate a diff of this commit: cvs rdiff -u -r1.6 -r1.7 src/sys/arch/pmax/include/loadfile_machdep.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- thorpej
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include
On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote:
Module Name:src
Committed By: matt
Date: Fri Aug 21 17:29:42 UTC 2009
Modified Files:
src/sys/arch/mips/include [matt-nb5-mips64]: types.h
Log Message:
Adapt to ABI variations. Make sure mips_reg_t == register_t.
Add PRIx{{P,V}{ADDR,SIZE}} and PRIxREGISTER{,32} macros to assist
printing out above types.
What's the point of having both? Why not just register_t and be done
with it
To generate a diff of this commit:
cvs rdiff -u -r1.43.36.1 -r1.43.36.2 src/sys/arch/mips/include/types.h
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
-- thorpej
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include
On Aug 22, 2009, at 4:30 PM, Matt Thomas wrote:
On Aug 22, 2009, at 4:25 PM, Jason Thorpe wrote:
On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote:
Module Name:src
Committed By: matt
Date: Fri Aug 21 17:29:42 UTC 2009
Modified Files:
src/sys/arch/mips/include [matt-nb5-mips64]: types.h
Log Message:
Adapt to ABI variations. Make sure mips_reg_t == register_t.
Add PRIx{{P,V}{ADDR,SIZE}} and PRIxREGISTER{,32} macros to assist
printing out above types.
What's the point of having both? Why not just register_t and be
done with it
Mostly to avoid casting. If it's X, use PRIxX and don't worry.
No, what's the point of having mips_reg_t ???
-- thorpej
Re: CVS commit: [matt-nb5-mips64] src/sys/arch/mips/include
Good point :-)
-- thor...@iphone
On Aug 22, 2009, at 6:28 PM, Matt Thomas wrote:
On Aug 22, 2009, at 6:28 PM, Jason Thorpe wrote:
On Aug 22, 2009, at 4:30 PM, Matt Thomas wrote:
On Aug 22, 2009, at 4:25 PM, Jason Thorpe wrote:
On Aug 21, 2009, at 10:29 AM, Matt Thomas wrote:
Module Name:src
Committed By:matt
Date:Fri Aug 21 17:29:42 UTC 2009
Modified Files:
src/sys/arch/mips/include [matt-nb5-mips64]: types.h
Log Message:
Adapt to ABI variations. Make sure mips_reg_t == register_t.
Add PRIx{{P,V}{ADDR,SIZE}} and PRIxREGISTER{,32} macros to assist
printing out above types.
What's the point of having both? Why not just register_t and be
done with it
Mostly to avoid casting. If it's X, use PRIxX and don't worry.
No, what's the point of having mips_reg_t ???
because I don't to change all that code right now? :)
Re: CVS commit: [matt-nb5-mips64] src/sys/conf
On Sep 4, 2009, at 9:19 PM, Matt Thomas wrote: On Sep 4, 2009, at 8:59 PM, Izumi Tsutsui wrote: Modified Files: src/sys/conf [matt-nb5-mips64]: Makefile.kern.inc Log Message: Don't abort if DBSYM fails. It was intentionally changed to fatal: http://cvsweb.NetBSD.org/bsdweb.cgi/src/sys/conf/Makefile.kern.inc#rev1.70 . Make this error a fatal build time error --- Izumi Tsutsui I see no reason to make it fatal. It means that when I build a kernel with DEBUG, my kernel build will fail. That's stupid. /u1/netbsd-nb5-mips64/tools/bin/mips64el--netbsd-strip -g -X -o netbsd netbsd.gdb /u1/netbsd-nb5-mips64/tools/bin/mips64el--netbsd-dbsym netbsd mips64el--netbsd-dbsym: symbol table (6124416 bytes) too big for buffer (175000 bytes) Increase options SYMTAB_SPACE in your kernel config -rwxr-xr-x 1 matt staff 9262360 Sep 4 20:28 MALTA64/netbsd -rwxr-xr-x 1 matt staff 29851080 Sep 4 20:28 MALTA64/netbsd.gdb We should figure out a way to make symbols "appendable" as an ELF section. textdata bss dec hex filename 2609483 223104 267656 3100243 2f4e53 MALTA64/netbsd 2609483 223104 267656 3100243 2f4e53 MALTA64/netbsd.gdb -- thorpej
Re: CVS commit: src/sys/dev/pci
On Sep 5, 2009, at 2:44 PM, David Young wrote: I think that we would add callbacks to many, many softc's, like we did with the enable/disable routines. Lots of code would be duplicated. I am gradually replacing those routines with self-suspension. PMF should handle bus-independent/bus-dependent suspend/resume, too. Let the programmer of drivers add a bus-dependent PMF hook in the bus attachment routine, and a bus-independent PMF hook in the generic attach routine. Something like this, for example, Yah, we could just define a protocol for PMF to call, and bus-specific subclasses can provide their own methods as necessary. Oh, nevermind. -- thorpej
Re: removing link sets (Re: CVS commit: src/usr.sbin/puffs/rump_smbfs)
On Sep 16, 2009, at 8:43 AM, Eric Haszlakiewicz wrote: On Wed, Sep 16, 2009 at 07:08:16AM +0400, Valeriy E. Ushakov wrote: PS: It's really amazing how rump can cope with link sets in the DSO world at all. One can condescentingly call it a hack, but link sets are not rump's fault. People are most welcome to fix this ugliness properly by helping to get rid of link sets in the kernel. getting rid of link sets? I thought they were added specifically to fix the need to have a bunch of ifdefs in code to initialize bits of code. What do you replace them with? Yes, I came to regret the addition of them. They solved a problem at one time, but are not really a great solution. I'd like to see them go, replaced with real constructor methods for each subsystem. eric -- thorpej
Re: CVS commit: src/usr.sbin/puffs/rump_smbfs
On Sep 18, 2009, at 9:10 AM, David Laight wrote: It is all rather similar to the proliferation of memory pools - for things where 'malloc' would be fine. The old-school kernel malloc was almost never "fine" ... but pools have another advantage -- use of a direct-mapped segment on architectures so-equipped. And for those not so-equipped, greatly reduced pressure on kmem_map. Now, if we could only get rid of kmem_map / kernel malloc completely (which requires making it illegal to allocate memory in interrupt context). -- thorpej
Re: CVS commit: src/sys
On Oct 2, 2009, at 8:48 AM, Antti Kantee wrote: Module Name:src Committed By: pooka Date: Fri Oct 2 15:48:42 UTC 2009 Modified Files: src/sys/conf: files src/sys/kern: kern_subr.c Added Files: src/sys/kern: subr_humanize.c Log Message: Give humanize_number & format_bytes their own spots in the sun and move from kern_subr to subr_humanize. This stuff really ought just to be in libkern. To generate a diff of this commit: cvs rdiff -u -r1.958 -r1.959 src/sys/conf/files cvs rdiff -u -r1.200 -r1.201 src/sys/kern/kern_subr.c cvs rdiff -u -r0 -r1.1 src/sys/kern/subr_humanize.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- thorpej
Re: CVS commit: src/lib/libc/arch/m68k/sys
On Oct 3, 2009, at 3:28 PM, Frank Wille wrote: Module Name:src Committed By: phx Date: Sat Oct 3 22:28:33 UTC 2009 Modified Files: src/lib/libc/arch/m68k/sys: cerror.S Log Message: SystemV-R4 ABI for M68k returns pointers in %a0, so we have to make sure that CERROR returns -1 in %a0 in addition to %d0 and %d1, to make functions like mmap(2), mremap(2), shmat(2) or sbrk(2) return -1 in case of an error. A side effect of this bug was a segfault caused by jemalloc, when mmap() failed. Wow, old bug. Nice find! To generate a diff of this commit: cvs rdiff -u -r1.14 -r1.15 src/lib/libc/arch/m68k/sys/cerror.S Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- thorpej
Re: CVS commit: src/etc/rc.d
On Oct 6, 2009, at 1:22 AM, Adam Hamsik wrote: > Hi, > On Oct,Tuesday 6 2009, at 9:03 AM, Alan Barrett wrote: > >> On Mon, 05 Oct 2009, Adam Hamsik wrote: >>> Modified Files: >>> src/etc/rc.d: mountall >>> >>> Log Message: >>> Add support for mounting zfs filesystems to mountall script. ZFS >>> configuration >>> is stored in /etc/zpool.cache and it is automatically loaded to kernel from >>> filesystem. Filesystems are then configured accordingly to their properties >>> loaded from cache file. >> >> Is /etc/zpool.cache a human-edited configuration file (in which >> case, why the ".cache" name?), or is it a machine-readable database (in >> which case, why is it in /etc?), or is it something else? > > It is a binary file. Something like binary plist. Do you have any better > place for it ? I think that we should keep it in etc until we start work on a > zfs on root support then we will need to move it some where else anyway. It belongs in /var/db ... but I'd like to ask why you need it at all? > > Regards > > Adam. -- thorpej
Re: panic? - Re: CVS commit: src
Surprising, since I specifically try to avoid an xcall in that case. I'll look later today. -- thor...@iphone On Oct 17, 2009, at 3:41 AM, Frank Kardel wrote: Hi Jason ! I now get a KASSERT() assertion failure during boot in subr_xcall.c:199: KASSERT(xc_tailp < xc_headp); Hand copied call stack: subr_xcall pool_cache_invalidate pmap_grow_kernel uvm_map_prepare uvm_map uvm_km_alloc vga_post_init ... more into autoconfig/device/bus scanning Frank Jason R Thorpe wrote: Module Name:src Committed By:thorpej Date:Thu Oct 15 20:50:13 UTC 2009 Modified Files: src/share/man/man9: pool_cache.9 src/sys/kern: subr_pool.c src/sys/sys: pool.h Log Message: - pool_cache_invalidate(): broadcast a cross-call to drain the per- CPU caches before draining the global cache. - pool_cache_invalidate_local(): remove. To generate a diff of this commit: cvs rdiff -u -r1.12 -r1.13 src/share/man/man9/pool_cache.9 cvs rdiff -u -r1.175 -r1.176 src/sys/kern/subr_pool.c cvs rdiff -u -r1.66 -r1.67 src/sys/sys/pool.h Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/kern
Thanks for fixing this! On Oct 20, 2009, at 10:24 AM, Jean-Yves Migeon wrote: > Module Name: src > Committed By: jym > Date: Tue Oct 20 17:24:22 UTC 2009 > > Modified Files: > src/sys/kern: subr_pool.c > > Log Message: > Fix a bug where on MP systems, pool_cache_invalidate(9) could be called > early during boot, just after CPUs are attached but before they are marked > as running. > > This will result in a list of CPUs without the SPCF_RUNNING flag set, and > will trigger the 'KASSERT(xc_tailp < xc_headp)' in xc_lowpri() as no cross > call is issued. > > Bug reported and patch tested by t...@. > > See also http://mail-index.netbsd.org/tech-kern/2009/10/19/msg006293.html > > > To generate a diff of this commit: > cvs rdiff -u -r1.176 -r1.177 src/sys/kern/subr_pool.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- thorpej
Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs
On Oct 29, 2009, at 4:25 PM, Bill Stouder-Studenmund wrote: > Where you able to look at the repository at macosforge.org before it shut > down? I think that would show a take at solving similar issues. Note that the XNU vnode lifecycle, referencing, and locking implementation is significantly different from ours. -- thorpej
Re: CVS commit: src
On Nov 2, 2009, at 9:08 PM, David Young wrote: > Module Name: src > Committed By: dyoung > Date: Tue Nov 3 05:08:19 UTC 2009 > > Modified Files: > src/sys/arch/i386/i386: copy.S > Added Files: > src/share/man/man9/man9.i386: return_address.9 > src/sys/arch/i386/include: return.h > > Log Message: > Add return_address(9) for reading the Nth return address from the call > stack. What's the intended usage? How is __builtin_return_address() not sufficient? > > > To generate a diff of this commit: > cvs rdiff -u -r0 -r1.1 src/share/man/man9/man9.i386/return_address.9 > cvs rdiff -u -r1.18 -r1.19 src/sys/arch/i386/i386/copy.S > cvs rdiff -u -r0 -r1.1 src/sys/arch/i386/include/return.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- thorpej
Re: CVS commit: src
On Nov 18, 2009, at 12:40 PM, David Young wrote: > I see. I will describe spllower(9) and splraise(9) in an i386 page, > instead. They should not be documented at all. They are not interfaces that are meant to be used in any user-serviceable way. -- thorpej
Re: CVS commit: src
On Nov 18, 2009, at 2:28 PM, Thomas E. Spanjaard wrote: > Jason Thorpe wrote: >> On Nov 18, 2009, at 12:40 PM, David Young wrote: >> >>> I see. I will describe spllower(9) and splraise(9) in an i386 page, >>> instead. >> >> They should not be documented at all. They are not interfaces that are >> meant to be used in any user-serviceable way. > > Section 9 isn't about "user-serviceable" interfaces anyway, unless the > user is a kernel developer, in which case it is relevant :). No, it's not. spllower() and splraise() are not really part of the kernel API. They are implementation details that can be described with comments in code. -- thorpej
Re: CVS commit: src/sys/dev/acpi
On Dec 3, 2009, at 1:04 PM, Christoph Egger wrote: > Module Name: src > Committed By: cegger > Date: Thu Dec 3 21:04:29 UTC 2009 > > Modified Files: > src/sys/dev/acpi: acpi.c files.acpi > Added Files: > src/sys/dev/acpi: acpi_pci.c acpi_pci.h > > Log Message: > Enumerate ACPI PCI devices. Allows to link PCI with ACPI devices. > Patch presented on tech-kern@ > http://mail-index.netbsd.org/tech-kern/2009/11/28/msg006552.html > Shouldn't we just attach PCI busses @ ACPI instead of mainbus? > 'nice work' Jukka Ruohonen > > > To generate a diff of this commit: > cvs rdiff -u -r1.136 -r1.137 src/sys/dev/acpi/acpi.c > cvs rdiff -u -r0 -r1.1 src/sys/dev/acpi/acpi_pci.c \ >src/sys/dev/acpi/acpi_pci.h > cvs rdiff -u -r1.62 -r1.63 src/sys/dev/acpi/files.acpi > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- thorpej
Re: CVS commit: src/share/man/man9
On Jan 25, 2010, at 1:33 PM, Jukka Ruohonen wrote: > The other places where it is currently used: > > * sys/arch/arm/xscale/becc_button.c > * sys/arch/evbarm/hdl_g/btn_obio.c > * sys/arch/evbarm/nslu2/nslu2_buttons.c > * sys/arch/hp700/dev/power.c > * sys/arch/landisk/dev/btn_obio.c > * sys/arch/landisk/dev/pwrsw_obio.c > * sys/arch/mips/atheros/dev/argpio.c > * sys/arch/sgimips/hpc/panel.c > * sys/arch/sparc/dev/tctrl.c > * sys/arch/sparc64/dev/psycho.c > * sys/arch/x68k/dev/pow.c > * sys/dev/adb/adb_kbd.c > * sys/arch/arm/xscale/becc_button.c > > ... and probably others. > > This makes it pretty "general" to me. At least for the "button" drivers above, it is used to interface with the sysmon_power framework (power button events, etc.) -- thorpej
Re: CVS commit: src/usr.sbin/powerd
On Jan 26, 2010, at 12:37 PM, Jukka Ruohonen wrote: > * Apparently there is only a single location for the scripts. Thus, remove > the references to "/etc/powerd/scripts/apm" and "/etc/powerd/scripts/acpi". This is incorrect. apm vs. acpi vs. whatever else.. the code still has support for them. Please put this back. Just because apm-specific and acpi-specific scripts do not yet exist doesn't mean that the code does not support them. -- thorpej
Re: CVS commit: src/usr.sbin/powerd
On Jan 26, 2010, at 2:26 PM, Paul Goyette wrote:
> The powerd(8) man page currently says
>
> The first location is /etc/powerd/scripts/, where
>is defined by the power management mechanism
> supported by the system, e.g., ``apm'' or ``acpi''. If the
> script is not found in the first location, powerd looks in
> /etc/powerd/scripts.
>
> This implies that the .../apm/... and .../acpi/... are optional. Yet
> src/usr.sbin/powerd.c has not been updated for more than two years, and it
> defines only a single path for locating the scripts.
>
> #define _PATH_POWERD_SCRIPTS"/etc/powerd/scripts"
>
>
>
> static const char *script_paths[] = {
> NULL,
> _PATH_POWERD_SCRIPTS
> };
>
if (ioctl(fd, POWER_IOC_GET_TYPE, &power_type) == -1) {
syslog(LOG_ERR, "POWER_IOC_GET_TYPE: %m");
exit(EX_OSERR);
}
(void)asprintf(&cp, "%s/%s", _PATH_POWERD_SCRIPTS,
power_type.power_type);
if (cp == NULL) {
syslog(LOG_ERR, "allocating script path: %m");
exit(EX_OSERR);
}
script_paths[0] = cp;
-- thorpej
Re: CVS commit: src
On Jan 27, 2010, at 11:10 AM, Matthias Drochner wrote: > Module Name: src > Committed By: drochner > Date: Wed Jan 27 19:10:31 UTC 2010 > > Modified Files: > src/distrib/sets/lists/comp: mi > src/include: util.h > src/lib/libutil: Makefile > Removed Files: > src/lib/libutil: pw_policy.3 pw_policy.c > > Log Message: > retire pw_policy(3) -- it is not found useful, there are other > (more common) ways to enforce a password strength policy > approved by elad bump the major version # of this library? > > > To generate a diff of this commit: > cvs rdiff -u -r1.1378 -r1.1379 src/distrib/sets/lists/comp/mi > cvs rdiff -u -r1.53 -r1.54 src/include/util.h > cvs rdiff -u -r1.62 -r1.63 src/lib/libutil/Makefile > cvs rdiff -u -r1.9 -r0 src/lib/libutil/pw_policy.3 > cvs rdiff -u -r1.14 -r0 src/lib/libutil/pw_policy.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- thorpej
Re: CVS commit: src
On Jan 27, 2010, at 2:21 PM, Matthias Drochner wrote: > > [removal from pw_policy from libutil] > thor...@shagadelic.org said: >> bump the major version # of this library? > > Hmm, in theory yes, but the code has never been used inside > the NetBSD tree, and there are good reasons to assume that > noone outside hasn't either. Ok, fair enough. It was only a suggestion :-) > > best regards > Matthias > > > > > > Forschungszentrum Juelich GmbH > 52425 Juelich > Sitz der Gesellschaft: Juelich > Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 > Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe > Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), > Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, > Prof. Dr. Sebastian M. Schmidt > > -- thorpej
Re: CVS commit: src/usr.sbin/powerd
On Jan 28, 2010, at 12:19 AM, Martin Husemann wrote: > - it is unclear how scripts could make use of the fact which subsystem > triggered the pmf event they are dealing with When I wrote that code, I did hot have a concrete example usage scenario for power-type-specific scripts, but since these scripts essentially embody configuration information, it did seem reasonable to allow for such a scenario. -- thorpej
Re: CVS commit: src
On Feb 3, 2010, at 12:56 PM, Roy Marples wrote: > Module Name: src > Committed By: roy > Date: Wed Feb 3 20:56:54 UTC 2010 > > Modified Files: > src/lib/libterminfo: Makefile genhash genman genthash > src/tools: Makefile > Added Files: > src/lib/libterminfo: hash.c termcap_hash.c terminfo.5 > Removed Files: > src/tools/nbperf: Makefile > > Log Message: > Store our generated files in CVS and remove nbperf from the toolchain. > This allows us to build consistent libs without an ever changing hash. > nbperf should still be in the toolchain ... even though it is not used by the build, it is still used as a developer tool. > > To generate a diff of this commit: > cvs rdiff -u -r1.2 -r1.3 src/lib/libterminfo/Makefile \ >src/lib/libterminfo/genhash > cvs rdiff -u -r1.1 -r1.2 src/lib/libterminfo/genman \ >src/lib/libterminfo/genthash > cvs rdiff -u -r0 -r1.1 src/lib/libterminfo/hash.c \ >src/lib/libterminfo/termcap_hash.c src/lib/libterminfo/terminfo.5 > cvs rdiff -u -r1.134 -r1.135 src/tools/Makefile > cvs rdiff -u -r1.1 -r0 src/tools/nbperf/Makefile > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- thorpej
Re: CVS commit: src/external/bsd/liblzf/dist
On Feb 3, 2010, at 3:58 PM, Joerg Sonnenberger wrote: > > Like I said, I don't have a problem with a fast, small compressor. But > it would strongly help to actually have a use case. As file format, I > object it, e.g. it seems to have no real header etc. Does it even really define a file format? Seems reasonable to let something else provide the container. > > Joerg -- thorpej
Re: CVS commit: src/sys/dev/pci
On Feb 4, 2010, at 1:13 AM, SAITOH Masanobu wrote: > Module Name: src > Committed By: msaitoh > Date: Thu Feb 4 09:13:23 UTC 2010 > > Modified Files: > src/sys/dev/pci: if_wm.c if_wmreg.h > > Log Message: > - Count Receive error, CRC error, Alignment error, Symbol error, Sequence > error, Carrier extension error and Receive length error into ierror. > Fixes PR#30349 reported by UMEZAWA Takeshi. > - Count Missed packet (rx fifo overflow) and Receive no buffers (rx ring full) > into iqdrops. Isn't iqdrops really meant for to reflect a drop when placing into the software queue above the driver? > > > To generate a diff of this commit: > cvs rdiff -u -r1.195 -r1.196 src/sys/dev/pci/if_wm.c > cvs rdiff -u -r1.35 -r1.36 src/sys/dev/pci/if_wmreg.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- thorpej
Re: CVS commit: src/sys/uvm
On Feb 12, 2010, at 6:36 AM, Hubert Feyrer wrote: > Replacing common code with a function sounds ok, but I've never seen either > size or "importance" as justification of a goto. goto is a useful construct, and there is nothing wrong with using it in the way it is being used here. -- thorpej
Re: CVS commit: src/external/cddl/osnet/lib/libnvpair
On Feb 17, 2010, at 11:10 AM, Nick Hudson wrote: > On Wednesday 17 February 2010 17:36:32 Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Wed Feb 17 17:36:32 UTC 2010 >> >> Modified Files: >> src/external/cddl/osnet/lib/libnvpair: Makefile >> >> Log Message: >> Fix build issue with our make system building libnvpair.so from libnvpair.c >> and libnvpair.so from *.so by renaming libnvpair.c to lib_nvpair.c > > Isn't it time to fix bsd.lib.mk to stop using .so for anything other than a > DSO? Agreed. > > I remember .pico being suggested last time this was brought up. > > Nick -- thorpej
Re: CVS commit: src/usr.sbin/acpitools/acpidump
> On Sep 14, 2021, at 1:34 PM, Roland Illig wrote: > > When lint runs on the code, it defines the preprocessor macro 'lint' to > be 1. Due to that, this name cannot be used as a regular identifier. Perhaps all of the "#ifdef lint" conditions should become "#ifdef __lint__"? -- thorpej
Re: CVS commit: src/sys
> On Sep 28, 2021, at 10:58 PM, matthew green wrote: > > "Jason R Thorpe" writes: >> Module Name: src >> Committed By:thorpej >> Date:Wed Sep 29 02:47:22 UTC 2021 >> >> Modified Files: >> src/sys/kern: sys_select.c uipc_socket.c >> src/sys/miscfs/fifofs: fifo_vnops.c >> src/sys/sys: select.h >> >> Log Message: >> - Change selremove_knote() from returning void to bool, and return >> true if the last knote was removed and there are no more knotes >> on the selinfo. >> - Use this new return value in filt_sordetach(), filt_sowdetach(), >> filt_fifordetach(), and filt_fifowdetach() to know when to clear >> SB_KOTE without having to know select/kqueue implementation details. > > kernel bump? it's certainly used in modules, but it's not > clear that it would break anything.. Not needed in this case. No callers that need the return value are in a module. -- thorpej
Re: CVS commit: src/sys
> On Sep 29, 2021, at 8:15 AM, Robert Elz wrote: > >Date:Wed, 29 Sep 2021 05:37:44 -0700 >From: Jason Thorpe >Message-ID: <39db6c46-94bf-4126-811b-466e5293b...@me.com> > > | Not needed in this case. > | No callers that need the return value are in a module. > > The problem with this argument is that it assumes that you know > every module that exists, anywhere. It might be true of the > modules distributed with NetBSD, without being true of some 3rd > party module. Anything that depends on the new return value would have simply been doing what the socket / fifo code was doing (groveling around in selinfo internals), so it's not like they're broken as a result of this change. -- thorpej
Re: CVS commit: src/sys/arch/x86/x86
I demand this change be reverted. (/s) > On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote: > > Module Name: src > Committed By: jmcneill > Date: Fri Oct 15 18:12:48 UTC 2021 > > Modified Files: > src/sys/arch/x86/x86: tsc.c > > Log Message: > Fix typo in comment: "porniters" -> "pointers" > > > To generate a diff of this commit: > cvs rdiff -u -r1.56 -r1.57 src/sys/arch/x86/x86/tsc.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src/sys/dev/cardbus
On Mar 4, 2010, at 10:49 AM, David Young wrote: > Use %zu and %zx for printf'ing bus_size_t. These aren't quite right. We should probably define PRIxxx macros for the bus.h scalar types. -- thorpej
Re: CVS commit: src/sys/dev/ic
On Mar 31, 2010, at 7:45 AM, David Young wrote:
> On Wed, Mar 31, 2010 at 05:09:41AM +, Michael Lorenz wrote:
>> Module Name: src
>> Committed By:macallan
>> Date:Wed Mar 31 05:09:41 UTC 2010
>>
>> Modified Files:
>> src/sys/dev/ic: pcf8584.c
>>
>> Log Message:
>> Do as OpenSolaris does and read the status register after each write.
>> Now this driver works on my Blade 2500.
>
> void
> pcfiic_write(struct pcfiic_softc *sc, bus_size_t r, u_int8_t v)
> {
> + volatile uint8_t junk;
>bus_space_write_1(sc->sc_iot, sc->sc_ioh, sc->sc_regmap[r], v);
> + junk = bus_space_read_1(sc->sc_iot, sc->sc_ioh, PCF_S1);
>bus_space_barrier(sc->sc_iot, sc->sc_ioh, sc->sc_regmap[r], 1,
>BUS_SPACE_BARRIER_WRITE);
> }
>
> I wonder, does the device need the read, or is the bus_space_barrier()
> insufficient to flush the write to the device?
bus_space_barrier() doesn't flush ... barriers only enforce the ordering of
operations (and, of course, with respect to non-overlapping addresses ...
obviously reads after writes of the same address in code will be enforced on
the bus without an explicit barrier).
>
> Dave
>
> --
> David Young OJC Technologies
> dyo...@ojctech.com Urbana, IL * (217) 278-3933
-- thorpej
Re: CVS commit: src/sys
On Apr 12, 2010, at 3:15 PM, Antti Kantee wrote: > Module Name: src > Committed By: pooka > Date: Mon Apr 12 22:15:32 UTC 2010 > > Modified Files: > src/sys/conf: files > src/sys/kern: kern_lwp.c > src/sys/sys: lwp.h > Added Files: > src/sys/kern: subr_lwp_specificdata.c > > Log Message: > Separate lwp specificdata data structure management from lwp cpu/vm > management. > > No functional change. > > (specificdata routines went from kern_lwp.c to subr_lwp_specificdata.c) I find this sort of re-factoring somewhat irritating. Can't you just #ifndef _RUMP_BUILD or some such so that we don't have to constantly split related functions into separate files? > > > To generate a diff of this commit: > cvs rdiff -u -r1.985 -r1.986 src/sys/conf/files > cvs rdiff -u -r1.143 -r1.144 src/sys/kern/kern_lwp.c > cvs rdiff -u -r0 -r1.1 src/sys/kern/subr_lwp_specificdata.c > cvs rdiff -u -r1.129 -r1.130 src/sys/sys/lwp.h > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. -- thorpej
Re: case-sensitive APFS volumes
> On Nov 13, 2019, at 1:57 AM, Christoph Badura wrote: > > Just HTF does one add the same cryptographic users that the / volume has? > TFM does not tell. It just says that "indeed, they should be added before > encryption". Hm, I'm not actually sure. I'll do a bit of research. > Maybe we can document this for the benfit of other NetBSD developers. > > And yes, I do *not* want to dink around in the Disk Utility GUI. > Automation or GTFO. All of these things should be possible with the diskutil command. -- thorpej
Re: CVS commit: src/sys/arch/arm/broadcom
> On Nov 28, 2019, at 2:21 AM, Jared McNeill wrote: > > I should have commented the code in gicv3 so that you would have realized it > was “unnecessarily complicated” for a reason :) Ok, I'll fix and add a comment. > > The interrupt_distribute(9) API makes an assumption that the return value of > anything_intr_establish can be used as input for the MD interrupt_distribute > implementation. For arm pic, struct intrsource * made most sense. It is a bit > of a hassle for fdtbus and really shows the need for an MI interrupt API. > > So where this breaks things is if you have something in the kernel do: > > Ih = fdtbus_intr_establish(…) > interrupt_distribute(ih, target, NULL) > > Currently the only place where this can happen is arch/arm/fdt/pmu_fdt.c but > IMHO the code is perfectly valid and could appear in other places in the > future. -- thorpej
Re: CVS commit: src/sys/kern
> On Dec 9, 2019, at 1:08 PM, Paul Goyette wrote: > > On Mon, 9 Dec 2019, Andrew Doran wrote: > >> Module Name: src >> Committed By:ad >> Date:Mon Dec 9 21:05:23 UTC 2019 >> >> Modified Files: >> src/sys/kern: kern_mutex.c >> >> Log Message: >> - Add a mutex_owner_running() for the benefit of the pagedaemon, which >> needs help with locking things in reverse order. > > Should this be added to the mutex(9) man page? Honestly, I think it should be protectively wrapped in something like __MUTEX_PRIVATE or some such, because it's not really something that things should be using except under very specialized circumstances. -- thorpej
Re: CVS commit: src/sys/uvm
> On Dec 23, 2019, at 7:22 PM, Taylor R Campbell > wrote: > > So I guess we won't be switching pg->phys_addr from paddr to pfn? If that's the case, we should rename the field. -- thorpej
Re: CVS commit: src/sys/arch
> On Dec 23, 2019, at 7:53 PM, Taylor R Campbell
> wrote:
>
>> Module Name:src
>> Committed By: thorpej
>> Date: Sun Dec 22 15:09:39 UTC 2019
>>
>> Add intr_mask() and corresponding intr_unmask() calls that allow specific
>> interrupt lines / sources to be masked as needed (rather than making a
>> set of sources by IPL as with spl*()).
>>
>> + if (ci == curcpu() || !mp_online) {
>> + intr_hwunmask_xcall(ih, NULL);
>> + } else {
>> + where = xc_unicast(0, intr_hwunmask_xcall, ih, NULL, ci);
>> + xc_wait(where);
>> + }
>
> If this conditional is necessary, we should teach xc_unicast to make
> it unnecessary.
Agreed. I followed the existing patter in intr.c. Andrew pointed out in code
review that the xcall code does at the the !mp_online bit now, but:
1- It does not do the curcpu() check.
2- It also fiddles with interrupt state.
For that reason, I was hesitant to make that change until further investigation
was done.
-- thorpej
Re: CVS commit: src/sys
> On Jan 3, 2020, at 10:11 AM, Frank Kardel wrote: > > Hi Jason ! > > Could you please check that kmem using tools can cope with the missing > _boottime symbol. Hey Frank... this should fix it: $NetBSD: vmstat.c,v 1.231 2020/01/03 19:13:54 thorpej Exp $ -- thorpej
Re: CVS commit: src/sys
> On Jan 3, 2020, at 5:08 PM, Simon Burge wrote: > > Hey Jason, > > Jason Thorpe wrote: > >>> On Jan 3, 2020, at 10:11 AM, Frank Kardel wrote: >>> >>> Hi Jason ! >>> >>> Could you please check that kmem using tools can cope with the missing >>> _boottime symbol. >> >> Hey Frank... this should fix it: >> >> $NetBSD: vmstat.c,v 1.231 2020/01/03 19:13:54 thorpej Exp $ > > Is it worth keeping the boottime symbol about so that a netbsd-9 vmstat > binary will still work with a -current kernel? We could possibly wrap > boottime with a COMPAT_90 check too?. Define "work". A dummy symbol would have no valid contents. I guess if you call that "work" then go ahead? The real problem here is that vmstat insists on finding the kernel symbols even if it's not going to use them, which is kind of silly. -- thorpej
Re: CVS commit: src/sys/dev/pci
> On Jan 9, 2020, at 2:54 AM, SAITOH Masanobu wrote:
>
> Module Name: src
> Committed By: msaitoh
> Date: Thu Jan 9 10:54:16 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: if_stge.c if_stgereg.h
>
> Log Message:
> Reduce diff against OpenBSD. No functional change.
>
> - USE CSR_{READ,WRITE}_*() macro.
> - Move some macros from if_stge.c to if_stgereg.h
This diff is incorrect. The macros that were moved to if_stgereg.h are not
related to hardware / register definitions, but are purely software constructs.
Please move them back to if_stge.c. Doing incorrect things simply to reduce
the diff against someone else's copy of the code is not something we should be
undertaking.
-- thorpej
Re: CVS commit: src/sys/dev/pci
> On Jan 9, 2020, at 6:11 PM, Masanobu SAITOH wrote: > > > Before my change, struct stge_softc is already in if_stgereg.h, > so I had thought it would be OK to move to it. Ah, I don't think I would have put it there when I wrote the driver originally, so it must have been moved there at some point. In any case, moving it into if_stgereg.h was also an error. > >> Please move them back to if_stge.c. Doing incorrect things simply to reduce >> the diff against someone else's copy of the code is not something we should >> be undertaking. > Two options: > > a) Move some structs (including struct stge_softc) and defines >to if_stge.c There is no reason to have if_stgevar.h, because no other modules need these definitions, so it should all move to if_stge.c. Thanks! > > b) Move them to new if_stgevar.h > > Which one is prefer? -- thorpej
Re: CVS commit: src/sys/dev/pci
> On Jan 9, 2020, at 9:02 PM, Masanobu SAITOH wrote: > > The reason why I moved stge_softc to if_stgereg.h was that ipgphy.c > required to check stge's chip revision. So, if there is no any objection, > I'll make new if_stgevar.h and share it with if_stge.c and ipgphy.c. That seems fine. Although it might be preferable to set a property on the parent dev_t and then query that from ipgphy, rather than accessing the softc. -- thorpej
Re: CVS commit: src/sys/arch/arm/include/arm32
> On Jan 11, 2020, at 8:32 PM, Izumi Tsutsui wrote: > > PGSHIFT is defined in and > PAGE_SHIFT and PAGE_SIZE is in , > but there is no common . Make a common that all of the platforms can #include, and just put these common definitions in it (for now)? -- thorpej
Re: CVS commit: src/sys/arch/arm/include/arm32
> On Jan 11, 2020, at 10:47 PM, Izumi Tsutsui wrote: > > thorpej@ wrote: > >>> PGSHIFT is defined in and >>> PAGE_SHIFT and PAGE_SIZE is in , >>> but there is no common . >> >> Make a common that all of the platforms can #include, and >> just put these common definitions in it (for now)? > > How about the attached diff? (untested, just for review) This looks good to me. -- thorpej
Re: CVS commit: src/sys/arch/x86
We should absolutely verify this under DEBUG. -- thorpej Sent from my iPhone. > On Jan 12, 2020, at 11:25 AM, Joerg Sonnenberger wrote: > > On Sun, Jan 12, 2020 at 01:01:12PM +, Andrew Doran wrote: >> Module Name:src >> Committed By:ad >> Date:Sun Jan 12 13:01:12 UTC 2020 >> >> Modified Files: >>src/sys/arch/x86/include: pmap.h pmap_pv.h >>src/sys/arch/x86/x86: pmap.c vm_machdep.c x86_tlb.c >> >> Log Message: >> x86 pmap: >> >> - It turns out that every page the pmap frees is necessarily zeroed. Tell >> the VM system about this and use the pmap as a source of pre-zeroed pages. > > Would it make sense to actually verify this under DEBUG? I fear the > debugging we have to do if a chance ever violates this assumption. > > Joerg
Re: CVS commit: src/sys
> On Jan 12, 2020, at 10:20 PM, Kamil Rytarowski wrote: > > While there, could we garbage collect unused defines from sys/param.h? > > I'm thinking in particular about: As long as we still have tsleep(9) and friends, we can't rid ourselves of these historical defines. Perhaps we should make a push to rid ourselves of those legacy interfaces? > > /* > * Historic priority levels. These are meaningless and remain only > * for source compatibility. Do not use in new code. > */ > #define PSWP0 > #define PVM 4 > #define PINOD 8 > #define PRIBIO 16 > #define PVFS20 > #define PZERO 22 > #define PSOCK 24 > #define PWAIT 32 > #define PLOCK 36 > #define PPAUSE 40 > #define PUSER 50 > #define MAXPRI 127 > > These symbols from time to time conflict with external loadable kernel > modules. My immediate offender is VirtualBox and PVM symbol name conflict. > -- thorpej
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)
> On Jan 13, 2020, at 8:15 AM, Izumi Tsutsui wrote:
>
> christos@ wrote:
>
>>> Now I get the following erro during local tests of
>>> "build.sh -U -m hp300 release" on NetBSD/i386 9.0_RC1 host:
>>>
>>> ---
>>> #create compat_util/compat_exec.d
> :
>>> In file included from /s/cvs/src/sys/sys/param.h:149:0,
>>>from /s/cvs/src/sys/compat/common/compat_exec.c:41:
>>> ./m68k/pmap_motorola.h:165:5: error: operator '*' has no left operand
>>> #if PAGE_SIZE == 8192 /* NBPG / (SG4_LEV1SIZE * sizeof(st_entry_t)) */
>>>^
>>> nbmkdep: compile failed.
>>> *** [compat_exec.d] Error code 1
>>
>> try cc -E?
>
> It turns out the problem is more complicated.
>
> has the following definitions:
>
> https://nxr.netbsd.org/xref/src/sys/uvm/uvm_param.h?r=1.38#135
I would suggest a possible workaround for this could be to define an additional:
#define __HAVE_FIXED_PAGE_SIZE
...at could also be tested here... the kernel truly does have a fixed page
size, but userland not necessarily so.
> ---
>135 * If MIN_PAGE_SIZE and MAX_PAGE_SIZE are not equal, then we must use
>136 * non-constant PAGE_SIZE, et al for LKMs.
>137 */
>138 #if (MIN_PAGE_SIZE != MAX_PAGE_SIZE)
>139 #define__uvmexp_pagesize
>140 #if defined(_LKM) || defined(_MODULE)
>141 #undef PAGE_SIZE
>142 #undef PAGE_MASK
>143 #undef PAGE_SHIFT
>144 #endif
>145 #endif
>146
>147 /*
>148 * Now provide PAGE_SIZE, PAGE_MASK, and PAGE_SHIFT if we do not
>149 * have ones that are compile-time constants.
>150 */
>151 #if !defined(PAGE_SIZE)
>152 extern const int *const uvmexp_pagesize;
>153 extern const int *const uvmexp_pagemask;
>154 extern const int *const uvmexp_pageshift;
>155 #definePAGE_SIZE (*uvmexp_pagesize) /* size of page
> */
>156 #definePAGE_MASK (*uvmexp_pagemask) /* size of page
> - 1 */
>157 #definePAGE_SHIFT (*uvmexp_pageshift) /* bits to
> shift for pages */
>158 #endif /* PAGE_SIZE */
> ---
>
> I.e. assumes PAGE_SIZE is not compile time constant
> for MODULEs if (MIN_PAGE_SIZE != MAX_PAGE_SIZE).
>
> Probably this is the same reason of recent arm build failures:
> https://releng.netbsd.org/builds/HEAD/202001130720Z/
> https://releng.netbsd.org/builds/HEAD/202001130720Z/evbarm-earm.build.failed
> ---
> /tmp/genassym.Lq8h9d/assym.c:57:1: error: asm operand 0 probably doesn't
> match constraints [-Werror]
> __asm("XYZZY VM_MIN_ADDRESS %0" : : "n" (VM_MIN_ADDRESS));
> ^
> /tmp/genassym.Lq8h9d/assym.c:58:1: error: asm operand 0 probably doesn't
> match constraints [-Werror]
> __asm("XYZZY VM_MAXUSER_ADDRESS %0" : : "n" (VM_MAXUSER_ADDRESS));
> ^
> /tmp/genassym.Lq8h9d/assym.c:97:1: error: asm operand 0 probably doesn't
> match constraints [-Werror]
> __asm("XYZZY PAGE_MASK %0" : : "n" (PAGE_MASK));
> ^
> /tmp/genassym.Lq8h9d/assym.c:98:1: error: asm operand 0 probably doesn't
> match constraints [-Werror]
> __asm("XYZZY PAGE_SIZE %0" : : "n" (PAGE_SIZE));
> ^
> ---
>
> Should we prepare independent constant for
> "possible pagesize value among different MACHINE with the same MACHINE_ARCH"
> for jemalloc(3)?
>
> ---
> Izumi Tsutsui
-- thorpej
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)
> On Jan 13, 2020, at 10:24 AM, Christos Zoulas wrote:
>
> Talking to myself:
>
> The arm PAGE_SIZE_{MIN,MAX} should go away after nick eliminates the
> need for the 8K pages. This leaves us with m68k to deal with...
> Do modules work on m68k? Should modules be shared between kernels with
> different page sizes? Then perhaps we don't need a new constant?
On m68k, I think the following two statements are true:
a) The platform should use a constant PAGE_SIZE to the extent possible because
it's a slow platform.
b) Modules should be built such that they can use a non-fixed PAGE_SIZE.
But (b) also requires that all of the OTHER non-same constants on m68k are
avoided (take a closer look at for example). Those
probably should be properly hidden from module builds so that we can at least
*catch* such cases.
-- thorpej
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)
> On Jan 14, 2020, at 8:41 AM, Izumi Tsutsui wrote: > >> b) Modules should be built such that they can use a non-fixed PAGE_SIZE. > > No, this is not necessary, because modules are built for each $MACHINE > and (a) each $MACHINE has fixed PAGE_SIZE. Yes, understood. I think it would eventually be a nice idea to make modules $MACHINE_ARCH-sharable, but it's not critical for now. -- thorpej
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)
> On Jan 14, 2020, at 10:16 AM, Christos Zoulas wrote: > > We do this to save space, but as you say, not important for now. Perhaps > the expedient solution is to define MALLOC_PAGE_SIZE... I'd rather keep the use of these constants separate... who knows what they might be used for in the future? Optimize #ifdef _KERNEL as-needed... -- thorpej
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)
> On Jan 14, 2020, at 2:37 PM, Christos Zoulas wrote:
>
> So what's the short term solution?
>
> - Don't define {MIN,MAX}_PAGE_SIZE on m68k?
> - Define a different constant?
> - Add a define to tell uvm to ignore {MIN,MAX}_PAGE_SIZE?
#ifdef _KERNEL, define {MIN,MAX}_PAGE_SIZE to a constant that matches the
system. For !_KERNEL, define MIN_PAGE_SIZE as 4096 and MAX_PAGE_SIZE as 8192.
Seems like that would do the trick.
-- thorpej
Re: CVS commit: src/sys [freeze on boot]
> On Jan 20, 2020, at 6:48 AM, Ryo ONODERA wrote: > > The black screen and ims(4) panic are not related to your change. > Older src tree with LOCKDEBUG reproduces these problem. I'll look at the ims(4) issuer. -- thorpej
Re: CVS commit: src/sys [freeze on boot]
> On Jan 20, 2020, at 3:44 PM, Christos Zoulas wrote: > > In article <20200120185023.gd28...@homeworld.netbsd.org>, > Andrew Doran wrote: >> Fix committed with sys/kern/kern_rwlock.c rev 1.62. I didn't see the >> problem as I am running with LOCKDEBUG. >> >> Apologies for the disruption. > > FYI: powerpc/arm do not build anymore... This should fix the powerpc problem: Index: lock_stubs.S === RCS file: /cvsroot/src/sys/arch/powerpc/powerpc/lock_stubs.S,v retrieving revision 1.10 diff -u -p -r1.10 lock_stubs.S --- lock_stubs.S28 Feb 2014 05:38:15 - 1.10 +++ lock_stubs.S21 Jan 2020 04:09:26 - @@ -101,8 +101,8 @@ ENTRY(mutex_exit) /* * void rw_enter(krwlock_t *krw, krw_t op); */ -#if RW_READ_INCR != 16 -#error RW_READ_INCR != 16, clrrXi need fixing +#if RW_READ_INCR != 32 +#error RW_READ_INCR != 32, clrrXi need fixing #endif #if RW_OWNER != 0 #error RW_OWNER != 0, ldptr should be ldptru @@ -115,7 +115,7 @@ ENTRY(rw_enter) bne-1f ldptr %r9,RW_OWNER(%r3) - clrrptri %r9,%r9,4 /* clear low 4 bits */ + clrrptri %r9,%r9,5 /* clear low 5 bits */ addi%r7,%r9,RW_READ_INCR b 2f 1: @@ -140,7 +140,7 @@ ENTRY(rw_tryenter) bne-1f ldptr %r9,RW_OWNER(%r3) - clrrptri %r9,%r9,4 /* clear low 4 bits */ + clrrptri %r9,%r9,5 /* clear low 5 bits */ addi%r7,%r9,RW_READ_INCR b 2f @@ -169,7 +169,7 @@ ENTRY(rw_exit) andi. %r0,%r9,RW_WRITE_LOCKED bne-1f - clrrptri. %r9,%r9,4 /* clear low 4 bits */ + clrrptri. %r9,%r9,5 /* clear low 5 bits */ beq-3f /* if 0, no reader, go slow */ addi%r7,%r9,-RW_READ_INCR > > http://releng.netbsd.org/builds/HEAD/202001201020Z/ > > christos > -- thorpej
Re: CVS commit: src/sys/arch/evbarm/conf
> On Jan 25, 2020, at 4:26 AM, Jared D. McNeill wrote: > > Module Name: src > Committed By: jmcneill > Date: Sat Jan 25 12:26:58 UTC 2020 > > Modified Files: > src/sys/arch/evbarm/conf: GENERIC GENERIC64 > > Log Message: > Follow amd64 and set AUDIO_BLK_MS=4 by default This seems a little silly to have in the kernel configuration file. I think there's an argument to be made that there should be a header that sets these defaults that can be tuned per-platform (or even some functionality to tune this at run-time). -- thorpej
Re: CVS commit: src/sys/arch/evbarm/conf
> On Jan 25, 2020, at 6:31 AM, Christos Zoulas wrote: > >> This seems a little silly to have in the kernel configuration file. I >> think there's an argument to be made that there should be a header that >> sets these defaults that can be tuned per-platform (or even some >> functionality to tune this at run-time). > > sysctl :-) Shouldn't HAVE to know about the sysctl, either. It should default to "good performance". -- thorpej
Re: CVS commit: src/sys/net
> On Jan 28, 2020, at 10:25 PM, Kamil Rytarowski wrote: > > The distribution build breaks for me with: Should be fixed with: /cvsroot/src/sys/rump/net/lib/libnet/Makefile,v <-- Makefile new revision: 1.33; previous revision: 1.32 > /public/netbsd-root/tooldir.NetBSD-9.99.38-amd64/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: > /public/netbsd-root/destdir.amd64/usr/lib/librumpnet_net.so: undefined > reference to `rumpns_if_stats_init' > /public/netbsd-root/tooldir.NetBSD-9.99.38-amd64/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: > /public/netbsd-root/destdir.amd64/usr/lib/librumpnet_net.so: undefined > reference to `rumpns_if_stats_fini' > /public/netbsd-root/tooldir.NetBSD-9.99.38-amd64/lib/gcc/x86_64--netbsd/8.3.0/../../../../x86_64--netbsd/bin/ld: > /public/netbsd-root/destdir.amd64/usr/lib/librumpnet_net.so: undefined > reference to `rumpns_if_stats_to_if_data' > -- thorpej
Re: CVS commit: src/sys
> On Feb 8, 2020, at 12:45 PM, Andrew Doran wrote: > > Bit concerning that we're growing a ton of kthreads in the network stack (my > test system now has something like 700 kthreads total) but I'm less worried > about that and moreso that a lot of these seem to be in the kernel RT range > and will therefore cause kernel preemptions when triggered. > > For something like a link state change that's no biggie but I'm not fond of > the idea of bulk wire & protcol processing needing mi_switch() + kpreempt(). > Way back when we made a concious decision not copy the design pattern our > sister project went with on this front. Maybe it is the right way to go now > but I think that should also be a concious design decision. Roger that. I agree with you -- I would prefer "regular" stuff to continue using softints. For some other stuff, though, we've made the policy decision that softints can't block for anything other than an adaptive mutex, which is fine... this particular case sends a message to the routing socket, which requires gathering interface statistics, which blocks on something other than an adaptive mutex. I'm not a fan of the workqueue interface, and I have something better sitting unfinished in my Bucket Of Stuff I'm Working On ... a generalized "task" interface originally written-but-not-finished by Taylor that uses either thread pools or softints to do the work... so at least the threads won't linger around in the "mostly idle" case. -- thorpej
Re: CVS commit: src/external/bsd/libarchive/dist/libarchive
I repled to you and gson off-list. > On Feb 25, 2020, at 8:24 AM, Kamil Rytarowski wrote: > > On 25.02.2020 16:24, Andreas Gustafsson wrote: >> Kamil Rytarowski wrote: >>> To generate a diff of this commit: >>> cvs rdiff -u -r1.1.1.4 -r1.2 \ >>>src/external/bsd/libarchive/dist/libarchive/archive_read.c >> >> What kind of sorcery is this? Why is the diff not relative to 1.1? >> > > I don't know. I was on the HEAD branch. > -- thorpej
Re: CVS commit: src/sys/arch/mips/mips
> On Mar 13, 2020, at 9:11 AM, Christos Zoulas wrote: > > I think this is better done in the driver, as other ports > do the same check and it catches bugs. x86 *explcitly* checks for 0 to skip work. If you want to find bugs, change the most-often-used implementation maybe? -- thorpej
Re: Modularize sun2 kernel (Re: CVS commit: src/sys/arch/sun2/conf)
> On Mar 14, 2020, at 7:57 PM, Rin Okuyama wrote: > > I think that we can no longer support 4MB system because of (2); hangs > due to (2) are much more serious for 4MB system than it is in 7MB system. > Modern kernel allocates too much things on demand rather than statically > allocating them in data segment... We should be striving to make that work. There are some redundant things (e.g. extent vs vmem) that we should explore getting rid of... and find ways to trim optionally functionality so we can keep these old systems running. -- thorpej
Re: Modularize sun2 kernel (Re: CVS commit: src/sys/arch/sun2/conf)
> On Mar 14, 2020, at 8:10 PM, Jason Thorpe wrote: > > redundant things (e.g. extent vs vmem) In case this wasn't obvious, I favor ejecting extent in favor of vmem. -- thorpej
Re: CVS import: src/external/broadcom/bwfm/dist
> On Mar 22, 2020, at 12:00 PM, Jason R Thorpe wrote: > > 3 conflicts created by this import. Note: These are false conflicts that are the result of the files being "cvs add"ed rather than imported originally. I verified before the import that all files that we currently distribute are identical to versions in the current linux-firmware snapshot. -- thorpej
Re: CVS commit: src/external/gpl3
> On Mar 25, 2020, at 5:26 PM, Kamil Rytarowski wrote: > > Upstream (GCC) is strongly against this change (even under __NetBSD__ > ifdef) as /var/tmp is typically larger than /tmp: > >> I'd strongly recommend against this as-is. >> >> The whole reason we prefer /var/tmp is because it's often dramatically > larger >> than a ram-backed /tmp. > > -- by Jeff Law. That's bonkers. It needlessly hurts performance and, on modern systems, adds needless SSD writes. -- thorpej
Re: CVS commit: src/sys
> On Mar 29, 2020, at 6:11 AM, Joerg Sonnenberger wrote: > > I would allow at least 1/HZ as baseline. Be careful, some platforms have a relatively high HZ (e.g. Alpha HZ=1024). -- thorpej
Re: CVS commit: src/sys
> On Mar 29, 2020, at 8:03 AM, Joerg Sonnenberger wrote: > > Yes and I see no fundamental reason for not allowing buffering with 1ms > frames in that case. I expect Alpha to be fast enough to do that with > little overhead. That's fine, I just wanted to point it out. -- thorpej
Re: CVS commit: src/sys/modules/examples/fopsmapper
> On Apr 1, 2020, at 7:17 AM, Christos Zoulas wrote: > > Which we have been slowly fixing. I think in this case the sign-compare > warnings are annoying, but putting casts on each warning is cluttering > the code needlessly. Unfortunately the alternative (to make the PAGESIZE > constant unsigned is more dangerous -- unless of course you are willing to > examine all the places it is used and make sure that the semantics don't > change). Another way would be to make: > >#define PAGESIZE_U ((unsigned)PAGESIZE) If PAGE_SIZE is ostensibly a vsize_t / size_t, why not define it as (1U << PAGE_SHIFT)? -- thorpej
Re: CVS commit: src/sys
> On Apr 3, 2020, at 5:45 AM, Tetsuya Isaki wrote: > > By the way, I am planning the following. How about this? I very much dislike creating an additional header file for this. I would prefer if the default were tuned for modern systems and overridable by a value exported (in a namespace-appropriate way) by a header that already exists on all platforms. -- thorpej
