Re: null-terminated vs. nul-terminated (was: Re: CVS commit: src/lib/libc/gen)

2022-03-26 Thread Jason Thorpe
> 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

Re: null-terminated vs. nul-terminated (was: Re: CVS commit: src/lib/libc/gen)

2022-03-26 Thread Jason Thorpe
> 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

Re: null-terminated vs. nul-terminated (was: Re: CVS commit: src/lib/libc/gen)

2022-03-26 Thread Jason Thorpe
> 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: CVS commit: src/sys/kern

2022-02-11 Thread Jason Thorpe
> On Feb 11, 2022, at 9:53 AM, Taylor R Campbell wrote: > > That is, this was presumably meant to ensure (A) happens-before (B). > This relation is already guaranteed by ipi(9), so there is no need > for any explicit memory barrier. Is this documented in ipi(9)? -- thorpej

Re: CVS commit: src/tests/fs/vfs

2022-02-02 Thread Jason Thorpe
> 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

Re: CVS commit: src/sbin/cgdconfig

2021-11-28 Thread Jason Thorpe
> 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

Re: CVS commit: src/sbin/cgdconfig

2021-11-28 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch/x86/x86

2021-10-15 Thread Jason Thorpe
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:

Re: CVS commit: src/sys

2021-09-29 Thread Jason Thorpe
> 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 th

Re: CVS commit: src/sys

2021-09-29 Thread Jason Thorpe
> 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:

Re: CVS commit: src/usr.sbin/acpitools/acpidump

2021-09-14 Thread Jason Thorpe
> 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

2021-08-25 Thread Jason Thorpe
> On Aug 24, 2021, at 10:21 PM, matthew green wrote: > >> - For alpha and sparc64, don't define MUTEX_CAS() in terms of their own >> _lock_cas(), which has its own memory barriers; the call sites in >> kern_mutex.c already have the appropriate memory barrier calls. Thus, >> alpha and

Re: CVS commit: src/sys

2021-07-31 Thread Jason Thorpe
> On Jul 31, 2021, at 3:17 AM, Tobias Nygren wrote: > > It's not possible to deduce from the manual what DesignWare revision > is used but I guess I can go over the data sheets of currently > released SoCs and build a matrix of the proper values regardless > of DesignWare revision. Have the

Re: CVS commit: [thorpej-i2c-spi-conf] src/sys/dev/i2c

2021-05-16 Thread Jason Thorpe
> On May 16, 2021, at 1:06 PM, matthew green wrote: > >> Modified Files: >> src/sys/dev/i2c [thorpej-i2c-spi-conf]: spdmem_i2c.c >> >> Log Message: >> The last change had an unfortunate side-effect on empty DIMM slots, so >> roll that back. Instead, if we used direct config, then probe

Re: CVS commit: src/sys/arch/powerpc/oea

2021-04-01 Thread Jason Thorpe
Ugh. Can we please stop making these hacky one-offs in "shared by all PowerPC platforms" code? This actually points to a deeper problem in the pmap code that needs to be addressed correctly. > On Apr 1, 2021, at 3:02 PM, Michael Lorenz wrote: > > Module Name: src > Committed By: macallan >

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-22 Thread Jason Thorpe
> On Feb 22, 2021, at 11:49 AM, Ryo Shimizu wrote: > > Ah, You are quite right! > idle/# lwp is provided and assigned for each CPU, so curcpu() obtained from > idle lwp was always the same. > So, there's no need to move curcpu() to after DISABLE_INTERRUPT. Please make sure to add a comment

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Jason Thorpe
> On Feb 16, 2021, at 1:56 PM, Roland Illig wrote: > > A downside of this test is that the macro from gets only > evaluated at compile time of the test. The test therefore cannot cover > future updates to without being reinstalled itself. But > at least for the release builds, it ensures a

Re: CVS commit: src/doc

2021-01-28 Thread Jason Thorpe
> On Jan 27, 2021, at 3:11 PM, Simon Burge wrote: > > It can run either big- or little-endian, but has virtually no IO support > whatsoever - just a UART and an extremely simple eithernet driver. > > I couldn't find any MIPS references to virtio with a quick look through > the QEMU 5.0

Re: CVS commit: src/sys/sys

2021-01-26 Thread Jason Thorpe
> On Jan 26, 2021, at 6:49 PM, Valery Ushakov wrote: > > It's hardly fair to characterize three people politely inquiring about > that choice and pointing out a more standard way to spell what you > want to express (that is perfectly in rhyme with the preceding table > and is only one

Re: CVS commit: src/sys/arch

2021-01-25 Thread Jason Thorpe
> On Jan 25, 2021, at 9:45 AM, Robert Elz wrote: > >Date:Mon, 25 Jan 2021 08:19:44 -0800 >From: Jason Thorpe >Message-ID: > > | Using { 0 } makes an assumption about the first member of the > | structure which is not guaranteed to remain

Re: CVS commit: src/sys/arch

2021-01-25 Thread Jason Thorpe
> On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote: > > I have no problem with this change but I am curious why should we use "{ > }"? It's a C GNU extension and C++ syntax. Using { 0 } makes an assumption about the first member of the structure which is not guaranteed to remain true. --

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

2021-01-25 Thread Jason Thorpe
> On Jan 24, 2021, at 10:20 PM, Martin Husemann wrote: > >> I kept getting a ?static after non-static declaration? error when building >> for aarch64. > > I guess that was with outdated arm/include/bus_funcs.h and > sys/bus_proto.h (or where was the previous declaration)? I did a “cvs

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

2021-01-24 Thread Jason Thorpe
> On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote: > > While I don't care for names, I would like to understand fallout in > details before hiding it - what exactly did not compile correctly? > At least the affected arm kernels worked for me in the state directly > before your commit. I

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

2021-01-23 Thread Jason Thorpe
> On Jan 23, 2021, at 5:40 PM, Christos Zoulas wrote: > >> it's a bad example. someone might copy it into another >> driver that _doesn't_ work with this version, but may seem >> to fix a build error. >> >> that's why i wanted to wrap the usage to make it clear if >> someone were to copy it

Re: CVS commit: src/sys/dev

2021-01-21 Thread Jason Thorpe
> On Jan 21, 2021, at 12:00 AM, Martin Husemann > wrote: > > On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote: >> Module Name: src >> Committed By:reinoud >> Date:Wed Jan 20 19:46:48 UTC 2021 >> > [..] >> Log Message: >> Add VirtIO PCI v1.0 attachments

Re: CVS commit: src/sys/netinet

2020-12-04 Thread Jason Thorpe
> On Dec 4, 2020, at 8:57 AM, Christos Zoulas wrote: > > In article <20201204004439.90c25f...@cvs.netbsd.org>, > Jason R Thorpe wrote: >> -=-=-=-=-=- >> >> Module Name: src >> Committed By:thorpej >> Date:Fri Dec 4 00:44:39 UTC 2020 >> >> Modified Files: >>

Re: CVS commit: src

2020-11-12 Thread Jason Thorpe
> On Nov 12, 2020, at 9:40 AM, nia wrote: > > For the record I'm just trying to fix things so that running > third-party software on NetBSD sucks less. If fewer third-party > libraries were exposed by the base system this wouldn't be > necessary. Why do we even have sqlite in the base system

Re: CVS commit: src/sys

2020-11-04 Thread Jason Thorpe
> On Nov 4, 2020, at 5:33 AM, Paul Goyette wrote: > > I guess I don't understand why a 32-bit architecture would also have > COMPAT_NETBSD32. In this particular case, it's for the old 32-bit ABI that predates the EABI standard the ARM port now uses. -- thorpej

Re: CVS commit: src/sys/arch/alpha/include

2020-09-03 Thread Jason Thorpe
> On Sep 3, 2020, at 1:14 PM, matthew green wrote: > > "Jason R Thorpe" writes: >> Module Name: src >> Committed By:thorpej >> Date:Thu Sep 3 04:20:54 UTC 2020 >> >> Modified Files: >> src/sys/arch/alpha/include: cpu.h >> >> Log Message: >> Garabage-collect

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

2020-07-17 Thread Jason Thorpe
> On Jul 17, 2020, at 3:50 PM, matthew green wrote: > > any chance you can look at NET_MPSAFE here etc? :) I have a bunch of local changes for this in one of my trees, and I hope to get back to it after netbsd-10 branches. -- thorpej

Re: CVS commit: src/sys

2020-07-08 Thread Jason Thorpe
> On Jul 8, 2020, at 12:22 AM, Martin Husemann wrote: > > On Tue, Jul 07, 2020 at 03:38:49AM +, Jason R Thorpe wrote: >> Provide a new resource provider API: > > This is *extremly* verbose and overflows message buffer, can you move the > new messages to aprint_debug or ifdef with some

Re: CVS commit: src/sys/arch/powerpc/booke

2020-07-06 Thread Jason Thorpe
> On Jul 6, 2020, at 5:28 PM, Rin Okuyama wrote: > > Module Name: src > Committed By: rin > Date: Tue Jul 7 00:28:31 UTC 2020 > > Modified Files: > src/sys/arch/powerpc/booke: e500_tlb.c > > Log Message: > Fix kernel panic due to tmpfs. > > pmap for booke assumes that the

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

2020-06-16 Thread Jason Thorpe
> 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 admitedly a very > ugly hack).

Re: CVS commit: src/common/lib/libprop

2020-06-11 Thread Jason Thorpe
> On Jun 11, 2020, at 4:28 PM, Kamil Rytarowski wrote: > >> Repeating that statement doesn't make it true. The amount of legit >> problems found by them is dwarfed by far by the number of false >> positives seen. That's complete ignoring basic QoI issues like "where is >> this actually

Re: CVS commit: src

2020-06-07 Thread Jason Thorpe
> On Jun 7, 2020, at 1:57 PM, Joerg Sonnenberger wrote: > >> Example? > > https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Function-Attributes.html#index-g_t_0040code_007bdeprecated_007d-attribute_002e-2502 I meant an example in our tree. We use __warn_reference() in several places already. I

Re: CVS commit: src

2020-06-07 Thread Jason Thorpe
> On Jun 7, 2020, at 1:22 PM, Joerg Sonnenberger wrote: > > On Sat, Jun 06, 2020 at 09:26:00PM +, Jason R Thorpe wrote: >> ==> Deprecate mutable prop_data(3) and prop_string(3) objects. The old >>APIs that support them still exist, but will now produce link-time >>warnings when

Re: CVS commit: src

2020-06-07 Thread Jason Thorpe
> On Jun 6, 2020, at 10:51 PM, matthew green wrote: > > "Jason R Thorpe" writes: >> Module Name: src >> Committed By:thorpej >> Date:Sat Jun 6 21:26:00 UTC 2020 >> >> Modified Files: >> src/lib/libprop: Makefile shlib_version > > i wonder, since this adds to

Re: CVS commit: src/sys/kern

2020-05-31 Thread Jason Thorpe
> On May 31, 2020, at 1:33 AM, Rin Okuyama wrote: > > db_show_callout(): struct callout_cpu and cpu_info are too much for stack. > > XXX > DDB can be running in the interrupt context, e.g., when activated from > console. Therefore, use kmem_intr_alloc(9) instead of kmem_alloc(9). > > Frame

Re: CVS commit: src/sys/arch/aarch64

2020-05-23 Thread Jason Thorpe
> On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote: > > Module Name: src > Committed By: ryo > Date: Sat May 23 18:08:59 UTC 2020 > > Modified Files: > src/sys/arch/aarch64/aarch64: cpufunc.c cpuswitch.S exec_machdep.c > genassym.cf netbsd32_machdep.c vectors.S

Re: Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-02 Thread Jason Thorpe
> On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote: > > Hi, > > Have you missed this thread? > > If the problem requires more time to investigate, > could you consider to revert ata change for a while? > > Thank you. I backed it out, but would appreciate some help tracking down the issue

Re: CVS commit: src

2020-04-26 Thread Jason Thorpe
> On Apr 26, 2020, at 5:23 AM, Maxime Villard wrote: > > Because I modeled my tests after the ufetchstore and threadpool tests which > are > both in this directory and provide user access to kernel internals via > modules, > which is exactly what I'm doing. ..and those are there because,

Re: CVS commit: src/sys/kern

2020-04-26 Thread Jason Thorpe
> On Apr 26, 2020, at 2:04 PM, Michael van Elst wrote: > > Log Message: > fix DIAGNOSTIC build non-DIAGNOSTIC you mean? -- thorpej

Re: CVS commit: src/sys/rump

2020-04-25 Thread Jason Thorpe
Why were any of these files touched by Xen changes? > On Apr 25, 2020, at 8:42 AM, Manuel Bouyer wrote: > > Module Name: src > Committed By: bouyer > Date: Sat Apr 25 15:42:15 UTC 2020 > > Modified Files: > src/sys/rump: listsrcdirs > src/sys/rump/dev/lib/libumass:

Re: CVS commit: src/sys

2020-04-24 Thread Jason Thorpe
> On Apr 24, 2020, at 3:39 AM, Kamil Rytarowski wrote: > > This is a good idea (and preexisting in other kernels), unfortunately we > had locking issues in rust. If a multithreaded process is forked, we > shall create a replica of a calling thread and keep mutexes functional. > We tried to

Re: CVS commit: src

2020-04-22 Thread Jason Thorpe
> On Apr 22, 2020, at 7:52 AM, Kamil Rytarowski wrote: > > Would it be possible to keep a global unique TID as 64-bit integer > (int64_t) equal to: pid << 32 | lwpid ? > > That way we could have predicatable numbers in the system and possibly > simplify the involved code avoiding one extra

Re: CVS commit: src/sys

2020-04-17 Thread Jason Thorpe
> On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > >Date:Fri, 17 Apr 2020 15:37:33 +0200 >From:Manuel Bouyer >Message-ID: <20200417133733.ga5...@antioche.eu.org> > > | And that would be a problem for me. I regulary update a single file to a > | specific

Re: CVS commit: src/sys

2020-04-17 Thread Jason Thorpe
> On Apr 17, 2020, at 6:28 AM, Rin Okuyama wrote: > > On 2020/04/17 22:14, Jason Thorpe wrote: >>> On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: >>> >>> For this, RCS and RCS semantics are irrelevant aren't they? >> No, not really. With the

Re: CVS commit: src/sys

2020-04-17 Thread Jason Thorpe
> On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: > > For this, RCS and RCS semantics are irrelevant aren't they? No, not really. With the modern systems, the "commit ID" identifies the state of the entire collection of files, not individual ones. Thus, you only need exactly one instance

Re: CVS commit: src/sys

2020-04-16 Thread Jason Thorpe
> On Apr 16, 2020, at 5:51 PM, Joerg Sonnenberger wrote: > > > That can be fixed generically? .ident needs the SHF_MERGE|SHF_STRINGS as > section flags and then the linker should do the rest by itself. Does it matter? The sooner we get off of "things that use RCS semantics" the better. --

Re: CVS commit: src/share/man/man4

2020-04-10 Thread Jason Thorpe
> On Apr 10, 2020, at 4:44 AM, m...@netbsd.org wrote: > > I had to stop using m_defrag because implementation details broke > bwfm@pci. It can only handle a chain of length 1, and m_defrag gives > a minimum of 2. Exactly. If it can compact the packet into a single cluster mbuf, it should do

Re: CVS commit: src/share/man/man4

2020-04-09 Thread Jason Thorpe
> On Apr 9, 2020, at 7:19 PM, SAITOH Masanobu wrote: > > You're welcome. > Some drivers still have no m_defrag() code, so we should add it > to them(). Others do something different than m_defrag() do essentially the same effect. Personally, I am not a huge fan of the m_defrag() API. --

Re: CVS commit: src/sys

2020-04-03 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/modules/examples/fopsmapper

2020-04-01 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys

2020-03-29 Thread Jason Thorpe
> 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

2020-03-29 Thread Jason Thorpe
> 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/external/gpl3

2020-03-25 Thread Jason Thorpe
> 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

Re: CVS import: src/external/broadcom/bwfm/dist

2020-03-22 Thread Jason Thorpe
> 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

Re: Modularize sun2 kernel (Re: CVS commit: src/sys/arch/sun2/conf)

2020-03-14 Thread Jason Thorpe
> 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: Modularize sun2 kernel (Re: CVS commit: src/sys/arch/sun2/conf)

2020-03-14 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch/mips/mips

2020-03-13 Thread Jason Thorpe
> 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: CVS commit: src/external/bsd/libarchive/dist/libarchive

2020-02-25 Thread Jason Thorpe
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 \ >>>

Re: CVS commit: src/sys

2020-02-08 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/net

2020-01-28 Thread Jason Thorpe
> 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 >

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

2020-01-25 Thread Jason Thorpe
> 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

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

2020-01-25 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys [freeze on boot]

2020-01-20 Thread Jason Thorpe
> 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. >

Re: CVS commit: src/sys [freeze on boot]

2020-01-20 Thread Jason Thorpe
> 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: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)

2020-01-14 Thread Jason Thorpe
> 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

Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)

2020-01-14 Thread Jason Thorpe
> 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

Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)

2020-01-14 Thread Jason Thorpe
> 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

Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)

2020-01-13 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys

2020-01-13 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch/x86

2020-01-12 Thread Jason Thorpe
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

Re: CVS commit: src/sys/arch/arm/include/arm32

2020-01-12 Thread Jason Thorpe
> 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)?

Re: CVS commit: src/sys/arch/arm/include/arm32

2020-01-11 Thread Jason Thorpe
> 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/dev/pci

2020-01-09 Thread Jason Thorpe
> 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.

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

2020-01-09 Thread Jason Thorpe
> 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

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

2020-01-09 Thread Jason Thorpe
> 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. > > -

Re: CVS commit: src/sys

2020-01-03 Thread Jason Thorpe
> 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 ca

Re: CVS commit: src/sys

2020-01-03 Thread Jason Thorpe
> 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/arch

2019-12-23 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/uvm

2019-12-23 Thread Jason Thorpe
> 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/kern

2019-12-09 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch/arm/broadcom

2019-11-28 Thread Jason Thorpe
> 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

Re: case-sensitive APFS volumes

2019-11-13 Thread Jason Thorpe
> 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

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

2019-09-21 Thread Jason Thorpe
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

Re: Leak Sanitizer - how to suppress leaks

2019-09-12 Thread Jason Thorpe
> 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

Re: CVS commit: src

2019-09-03 Thread Jason Thorpe
> 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 >

Re: CVS commit: src

2019-09-03 Thread Jason Thorpe
> 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/sys

2019-07-23 Thread Jason Thorpe
> On Jul 23, 2019, at 10:07 AM, Jason Thorpe wrote: > > > >> On Jul 23, 2019, at 9:14 AM, Rin Okuyama wrote: >> >> Ah, you are right. We leaks uninitialized memory via mmap. >> >> However, I'm not sure that it is safe to write DMA buffer >

Re: CVS commit: src/sys

2019-07-23 Thread Jason Thorpe
> On Jul 23, 2019, at 9:14 AM, Rin Okuyama wrote: > > Ah, you are right. We leaks uninitialized memory via mmap. > > However, I'm not sure that it is safe to write DMA buffer > above sc->sc_vramsize after bus_dmamap_load? > > Thoughts, ARM experts? Since fundamental memory allocation is

Re: CVS commit: src/sys/compat/sys

2019-06-28 Thread Jason Thorpe
> On Jun 26, 2019, at 7:10 PM, matthew green wrote: > >> Always include the 32 bit structure and definitions on _LP64 regardless >> of compat32 being on or off, because we want the headers to work when >> compiling modular kernels. Of course the 32 bit structs do not make sense >> on platforms

Re: CVS commit: src/sys/arch/x86/x86

2019-05-15 Thread Jason Thorpe
> On May 15, 2019, at 9:19 PM, Maxime Villard wrote: > > Le 16/05/2019 à 04:36, SAITOH Masanobu a écrit : >> Module Name: src >> Committed By:msaitoh >> Date:Thu May 16 02:36:30 UTC 2019 >> Modified Files: >> src/sys/arch/x86/x86: procfs_machdep.c >> Log Message:

Re: CVS commit: src/sys

2019-05-13 Thread Jason Thorpe
> On May 13, 2019, at 7:17 AM, Greg Troxel wrote: > > 2) Your option 2 seems to involve two things at once: > > - migration to lwp_specificadata > - using DEBUG instead of DIAGNOSTIC to control the leak check feature > > I do not understand why changing the nature of the implementation is

Re: CVS commit: src/tools

2019-05-07 Thread Jason Thorpe
> On May 7, 2019, at 3:52 PM, Herbert J. Skuhra wrote: > > On Tue, 07 May 2019 12:23:12 +0200, "J. Hannken-Illjes" wrote: >> >> >>> On 7. May 2019, at 12:17, matthew green wrote: >>> Diff is NOT reversed. >>> >>> ah yes, i see. please commit. > > Crossbuilding is still broken. I

Re: CVS commit: src/tools

2019-05-07 Thread Jason Thorpe
I'll take a look at this this evening. > On May 7, 2019, at 3:52 PM, Herbert J. Skuhra wrote: > > On Tue, 07 May 2019 12:23:12 +0200, "J. Hannken-Illjes" wrote: >> >> >>> On 7. May 2019, at 12:17, matthew green wrote: >>> Diff is NOT reversed. >>> >>> ah yes, i see. please commit. >

Re: CVS commit: src/tools

2019-05-07 Thread Jason Thorpe
> On May 7, 2019, at 12:32 PM, matthew green wrote: > > did you start from a clean *tooldir*? that would be the bit > that matters. if one had an existing tooldir with nbpax in > it, then this problem wouldn't occur. > > that's my only guess to what happened... Yah, that's probably it.

Re: CVS commit: src/tools

2019-05-07 Thread Jason Thorpe
> On May 7, 2019, at 3:17 AM, matthew green wrote: > >> Diff is NOT reversed. > > ah yes, i see. please commit. I bootstrapped the whole system 3 or 4 times without having this extra dependency and didn't see a build failure, so I'm a little confused, but whatever. Thanks for fixing it.

Re: CVS commit: src/sys/compat/freebsd

2019-04-06 Thread Jason Thorpe
> On Apr 6, 2019, at 10:45 AM, Robert Elz wrote: > > Actually, fetching & storing registers (register_t) is a common enough > thing that it might be worth having ufetch_reg (and ustore_reg), probably > as MD #defines that map into one of the other calls. The only situation I know of where

Re: CVS commit: src/sys/arch/x86/acpi

2019-03-03 Thread Jason Thorpe
> On Mar 3, 2019, at 10:31 AM, m...@netbsd.org wrote: > > Maybe we can use the longer name to avoid the confusion? PG_WIRED > > (PG_W as writable exists in other archs, and there's precedence for > PG_WIRED too) Agreed, PG_WIRED is a better name for this. -- thorpej

  1   2   >