> On Jan 1, 2019, at 8:02 AM, Robert Swindells wrote:
>
> How does the usage of libLLVM from MesaLib make use of the LLVM headers
> at *runtime* ?
>
> If they are not needed at runtime then why do they need to be installed
> on a target machine ?
What's needed on the target machine are the
> On Jan 1, 2019, at 6:34 AM, Martin Husemann wrote:
>
> Can you explain how the MesaLib build uses llvm?
>
> This kinda sounds like you need a special build time binary that would
> live in $TOOLDIR and it is not exactly clear how installing some headers
> helps building this tool (as you
> On Jan 1, 2019, at 11:23 AM, Martin Husemann wrote:
>
> Yeah (and to waste more than an additional hour in a full build of
> NetBSD) - but then we need a working plan how to provide libllvm as
> part of the installed system, not only headers for building libmesa.
I'm not arguing the merits
> On Jan 1, 2019, at 8:26 PM, m...@netbsd.org wrote:
>
> Having two versions of LLVM in use by a binary is going to fail in
> surprising ways.
>
> Base can be several years old at some point, increasing the odds of the
> LLVM non-compatibility biting us.
> And libGL is very widely used.
> On Jan 1, 2019, at 9:23 PM, m...@netbsd.org wrote:
>
> I'll note I don't know of a single package using LLVM and a library as
> well as libGL, even though it looks like it should be a likely scenario.
>
> The closest example was Octave that uses 3D graphs (with acceleration)
> and at some
> On Jan 1, 2019, at 9:53 PM, m...@netbsd.org wrote:
>
>> You're conflating two things that aren't related. Mesa's use of LLVM is
>> conceptually similar to the "Canadian cross", and at no point should the
>> compiler run-times of the "build", "host", or "target" systems ever
>>
> On Jan 6, 2019, at 5:36 AM, Martin Husemann wrote:
>
> On Sun, Jan 06, 2019 at 08:31:53AM -0500, Greg Troxel wrote:
>> Why do we generate code with unaligned access in user space? That seems
>> surprising, if the processor isn't happy about it.
>
> The processor is happy with it, both in
Panic seems not optimal. A rate limited log message at LOG_ERROR seems better.
-- thorpej
Sent from my iPhone.
> On Dec 13, 2018, at 12:54 PM, Rin Okuyama wrote:
>
> Module Name:src
> Committed By:rin
> Date:Thu Dec 13 20:54:50 UTC 2018
>
> Modified Files:
>src/sys/net:
> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell
> wrote:
>
> Caveat: Need to
> take care of the lwp name in threadpool_job_done so that we never
> point at the job_name of a job in oblivion.
Something like this.
Index: kern_threadpool.c
I think this the way to go. I’ll look at it a little later tonight.
-- thorpej
Sent from my iPhone.
> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell
> wrote:
>
> 2. Chuck the job reference count altogether. Just use job_thread as a
> proxy for whether it's in use. User must not call
>
> On Dec 26, 2018, at 7:52 PM, Taylor R Campbell
> wrote:
>
> Probably wanna dereference job->job_thread _before_ setting it to
> NULL!
Picky, picky :-)
Index: kern_threadpool.c
===
RCS file:
> On Dec 26, 2018, at 10:04 AM, Taylor R Campbell
> wrote:
>
> Can you use a module initialization routine for this, or call it in
> main if you don't want to deal with modules, instead of sprinkling
> RUN_ONCE in various places?
I thought about using a module initializer, the timing of
> On Dec 26, 2018, at 5:25 PM, Jason Thorpe wrote:
>
> I think this the way to go. I’ll look at it a little later tonight.
>
> -- thorpej
> Sent from my iPhone.
>
>> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell
>> wrote:
>>
>> 2. Chuck
> On Dec 26, 2018, at 8:32 PM, Taylor R Campbell
> wrote:
>
> LGTM if it works!
Doesn't trip any asserts in the unit tests... I'm going to push this in and
then do the ref counting change as a separate commit.
-- thorpej
> On Dec 27, 2018, at 6:04 AM, Jason Thorpe wrote:
>
> -- job_hold remains lockless, but job_rele can only be called **without** the
> job_lock held, because it needs to acquire the lock in the unlikely case it
> performs a cv_broadcast (see below). Also need a job_rele_lock
> On Dec 24, 2018, at 9:51 PM, m...@netbsd.org wrote:
>
> Heavily contended whitespace
Cage match material.
-- thorpej
> On Dec 14, 2018, at 2:05 PM, Michael Lorenz wrote:
>
> Module Name: src
> Committed By: macallan
> Date: Fri Dec 14 22:05:36 UTC 2018
>
> Modified Files:
> src/sys/dev/i2c: ds1307.c files.i2c
>
> Log Message:
> add options DSRTC_YEAR_START_2K for machines which use 2000 and
> On Dec 15, 2018, at 2:30 AM, SAITOH Masanobu wrote:
>
> Module Name: src
> Committed By: msaitoh
> Date: Sat Dec 15 10:30:58 UTC 2018
>
> Modified Files:
> src/sys/dev/usb: if_urtwn.c
>
> Log Message:
> Make IODATA WN-G150UMW work:
> - Increase delay to prevent "could not
> On Dec 3, 2018, at 11:27 AM, Christos Zoulas wrote:
>
> I don't think that the things that KASLR randomizes by default are useful
> to debugging. I.e. you can't depend on two successive kernel crashes to
> have identical PTE addresses; OTOH you can depend that the text addresses
> are the
Fixed.
> On Dec 9, 2018, at 7:50 AM, Jason Thorpe wrote:
>
> Investigating now...
>
>> On Dec 9, 2018, at 7:39 AM, m...@netbsd.org wrote:
>>
>> On Sat, Dec 08, 2018 at 05:46:15PM +, Jason R Thorpe wrote:
>>> @@ -2508,13 +2525,7 @@ c
Investigating now...
> On Dec 9, 2018, at 7:39 AM, m...@netbsd.org wrote:
>
> On Sat, Dec 08, 2018 at 05:46:15PM +, Jason R Thorpe wrote:
>> @@ -2508,13 +2525,7 @@ comcnattach(bus_space_tag_t iot, bus_add
>> {
>> struct com_regs regs;
>>
>> -memset(, 0, sizeof regs);
>> -
Thanks! This has been bothering me for a while, but I hadn’t had a chance to
look at it.
-- thorpej
Sent from my iPhone.
> On Nov 19, 2018, at 8:14 AM, Christos Zoulas wrote:
>
> Module Name:src
> Committed By:christos
> Date:Mon Nov 19 08:14:28 UTC 2018
>
> Modified Files:
Shouldn't this be instead?
IMO, pulling in implicitly is generally harmful (there is a lot
of namespace pollution there...)
> On Nov 19, 2018, at 9:23 AM, Maya Rashish wrote:
>
> Module Name: src
> Committed By: maya
> Date: Mon Nov 19 09:23:05 UTC 2018
>
> Modified Files:
>
> On Jan 13, 2019, at 5:08 PM, David Holland
> wrote:
>
> Is there a way we could, for example, leverage the current hacks for
> chowning console devices to grant access to wpa_supplicant?
Some of this could be achieved with ttyaction(5), certainly.
-- thorpej
> On Jan 13, 2019, at 5:21 AM, Greg Troxel wrote:
>
> Even if you have to be root, these changes are still hugely useful.
> "sudo wpa_cli" is not that hard, even if it seems like it should not be
> necessary.
...but made slightly more annoying seeing as how sudo is not part of the base
OS.
> On Dec 28, 2018, at 6:06 AM, Cherry G.Mathew wrote:
>
> I don't like the imperative in your tone. NVMM is the user of modloader,
> not PVHVM. So if you feel like your usecase needs fixing, I'd say it's
> your problem - or don't use modules, but see below.
...but as the person who committed
> On Dec 26, 2018, at 4:11 PM, Taylor R Campbell
> wrote:
>
> Job reference counting is currently slightly busted -- my draft for
> threadpool_schedule_job didn't increment it correctly, and your
> threadpool_schedule_job doesn't handle failure in threadpool_job_hold.
Ok, I looked at this
> On Dec 28, 2018, at 10:14 AM, Mathew, Cherry G. wrote:
>
> ic, this probably explains why it's used sparingly so far. Thanks for the
> explanation. I'll try to educate myself on this wrt enabling this for modload.
We use weak symbols all over the place in user space. It's just that the
> On Dec 30, 2018, at 6:51 AM, Sevan Janiyan wrote:
>
> Modified Files:
> src/sys/arch/evbmips/conf: ADM5120 ADM5120-NB ADM5120-USB ALCHEMY AP30
> CI20 CPMBR1400 DB120 ERLITE GDIUM LINKITSMART7688 LOONGSON MALTA
> MERAKI RB153 RB433UAH SBMIPS WGT624V3 XLSATX ZYXELKX
> On Dec 28, 2018, at 6:44 PM, John Nemeth wrote:
>
> However, having said that, I suspect that your work with PVHVM
> (and presumably PVH after that) will make the idea of having seperate
> modules for Xen obsolete. I.e. it appears to me that we're headed
> to a world where a single
> On Dec 30, 2018, at 4:34 PM, Sevan Janiyan wrote:
>
> On 30/12/2018 16:16, Jason Thorpe wrote:
>> Maybe create a std.evmips that the various std. files can
>> include to get options that you want for everything?
>
> Noted, I was thinking about the pull up
> On Dec 28, 2018, at 1:32 PM, Paul Goyette wrote:
>
> The in-kernel linker doesn't deal with weak symbols at all. It would
> need a lot of thought to get it right. For example, if module A
> (containing a weak reference) gets loaded, its weak references don't
> resolve. Then module B gets
> On Jan 28, 2019, at 8:11 AM, Masanobu SAITOH wrote:
>
> On 2019/01/28 15:07, Jason Thorpe wrote:
>> Doesn’t it seem a little dangerous to just blindly enable?
>
> You mean it should be enable only when the secondary bridge is configured
> correctly?
>
> Bo
Doesn’t it seem a little dangerous to just blindly enable?
-- thorpej
Sent from my iPhone.
> On Jan 28, 2019, at 6:09 AM, SAITOH Masanobu wrote:
>
> Module Name:src
> Committed By:msaitoh
> Date:Mon Jan 28 04:09:51 UTC 2019
>
> Modified Files:
>src/sys/dev/pci: ppb.c
>
>
> 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
> 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
> 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
> 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
> 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
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 \
>>>
> 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
> 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
> 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
>
> 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
> 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.
>
> -
> 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
> 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)?
> 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
> 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
> 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
> 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
> 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
> 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
> 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.
>
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
> 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.
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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.
--
> 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
> 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
> 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.
--
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
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:
> 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
> 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
> 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
> On Apr 26, 2020, at 2:04 PM, Michael van Elst wrote:
>
> Log Message:
> fix DIAGNOSTIC build
non-DIAGNOSTIC you mean?
-- thorpej
> 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,
> 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
> 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
> 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
> 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
> 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
> 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).
> 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
> 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
> 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
> 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
> 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
> 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
> 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:
>>
> 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
> 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
> 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
> 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
> 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.
--
> 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
1 - 100 of 192 matches
Mail list logo
