On Mon, 22 Feb 2021, Ryo Shimizu wrote:
I think this condition is not necessary since cpu_idle() is just called from
idle_loop(),
and ci_intr_depth is always zero at this time.
Ah yes, my mistake! Please feel free to revert this commit as part of
your proposed change.
> 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
>> In addition, because of the possibility of kpreemption (but aarch64 has =
>no KPREEMPT yet),
>> the acquisition of curcpu() is moved to after DISABLE_INTERRUPT and got =
>the following.
>>
>[snip]
>
>
>>
>> Is this ok?
>>
>
>Looks good - I wonder if the fact that curcpu is an invariant for
On 22/02/2021 10:40, Ryo Shimizu wrote:
Module Name:src
Committed By: jmcneill
Date: Sun Feb 21 23:37:10 UTC 2021
Modified Files:
src/sys/arch/aarch64/aarch64: idle_machdep.S
Log Message:
When waking from cpu_idle(), only call dosoftints if ci_intr_depth == 0
To
>Module Name: src
>Committed By: jmcneill
>Date: Sun Feb 21 23:37:10 UTC 2021
>
>Modified Files:
> src/sys/arch/aarch64/aarch64: idle_machdep.S
>
>Log Message:
>When waking from cpu_idle(), only call dosoftints if ci_intr_depth == 0
>
>
>To generate a diff of this commit:
>cvs
On Wed, Feb 17, 2021 at 11:51:04PM +, David A. Holland wrote:
> Also, Someone(TM) should check if POSIX permits this or if we ought to
> improve the implementation.
Unsurprisingly, POSIX is silent. It just says "rewinddir shall also
cause the directory stream to refer to the current state
In article <5912ca9e-b4e7-423d-a45d-f4693d1c9...@zoulas.com>,
Christos Zoulas wrote:
>-=-=-=-=-=-
Here's the final changes
- Make ALIGNED_POINTER use __alignof(t) instead of sizeof(t). This is more
correct because it works with non-primitive types and provides the ABI
alignment for the
> On Feb 17, 2021, at 4:20 PM, Valery Ushakov wrote:
>
> On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote:
>
> This incrementally improves wrong things b/c you still have the "is
> aligned" and "ought to be aligned" conflated in one.
The incremental patch improves things and
On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote:
> In article ,
> Valery Ushakov wrote:
>
> >But to get back to my main point, PLEASE, can we stop making random
> >aimless changes without prior discussion?
>
> Here's the change I'd like to make:
> - pass the alignment instead of
In article ,
Valery Ushakov wrote:
>But to get back to my main point, PLEASE, can we stop making random
>aimless changes without prior discussion?
Here's the change I'd like to make:
- pass the alignment instead of the mask (as Roy asked and to match the
other macro)
- use alignof to
Jared,
please test if the attached diff is sufficient.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
uvm_swap.c.diff
Description: Binary data
> On 17. Feb 2021, at 13:07, Jared McNeill wrote:
>
> I noticed this on reboot since this change:
>
> [ 3636.2891122] turning
I noticed this on reboot since this change:
[ 3636.2891122] turning off swap...stopping swap on /swap failed with error 16
[ 3636.2991109] stopping swap on /swap2 failed with error 16
Can you have a look?
Thanks!
Jared
On Tue, 16 Feb 2021, Juergen Hannken-Illjes wrote:
Module Name:
On Tue, Feb 16, 2021 at 18:51:43 -0500, Christos Zoulas wrote:
> On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote:
> -- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)
>
> | Well, it was you who did the definion of ALIGNED_POINTER centralized
> |
On Wed, Feb 17, 2021 at 00:51:03 +0100, Roland Illig wrote:
> 17.02.2021 00:25:10 Valery Ushakov :
> > On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
> >> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the
> >> test is for.
> >>
> >> I intentionally placed it
On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)
| Well, it was you who did the definion of ALIGNED_POINTER centralized
| and overridable :)
|
| revision 1.400
| date: 2012-01-25 00:03:36 +0400; author: christos
17.02.2021 00:25:10 Valery Ushakov :
> On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
>> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the
>> test is for.
>>
>> I intentionally placed it between (which defines that
>> macro on x86 and some other platforms) and
On 16.02.2021 23:32, Jason Thorpe wrote:
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
On Tue, Feb 16, 2021 at 17:53:09 -0500, Christos Zoulas wrote:
> In this case "type" is a struct and we have __alignof() to handle
> it, but does this give the right answer?
>
> Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT and
> can be overriden (the opposite goes for
On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
> On 16.02.2021 23:40, Valery Ushakov wrote:
> > On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
> >
> > > On 16.02.2021 19:46, Roy Marples wrote:
> > > > I suggest we change POINTER_ALIGNED_P to accept the alignment value
On 16.02.2021 23:40, Valery Ushakov wrote:
On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
On 16.02.2021 19:46, Roy Marples wrote:
I suggest we change POINTER_ALIGNED_P to accept the alignment value we
want rather than the bitwise test we supply, like so:
#define
In this case "type" is a struct and we have __alignof() to handle it, but does
this give the
right answer? Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT
and can be overriden (the opposite goes for POINTER_ALIGNED_P) I am all for
having one
macro, but how can we satisfy all
On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
> On 16.02.2021 19:46, Roy Marples wrote:
> > I suggest we change POINTER_ALIGNED_P to accept the alignment value we
> > want rather than the bitwise test we supply, like so:
> >
> > #define POINTER_ALIGNED_P(p, a) (((uintptr_t)(p) &
> 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
On 16.02.2021 19:46, Roy Marples wrote:
I suggest we change POINTER_ALIGNED_P to accept the alignment value we
want rather than the bitwise test we supply, like so:
#define POINTER_ALIGNED_P(p, a) (((uintptr_t)(p) & ((a) - 1))
That's a good definition, clear, simple, obvious,
Yes, I agree. I am going to change that.
christos
> On Feb 16, 2021, at 1:46 PM, Roy Marples wrote:
>
> Hi Christos
>
> On 14/02/2021 20:58, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun Feb 14 20:58:35 UTC 2021
>> Modified Files:
>>
Hi Christos
On 14/02/2021 20:58, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun Feb 14 20:58:35 UTC 2021
Modified Files:
src/sys/net: if_arp.h if_bridge.c
src/sys/netinet: icmp_private.h if_arp.c igmp_var.h in_l2tp.c ip_flow.c
On Tue, Feb 16, 2021 at 09:29:15AM +, Roy Marples wrote:
> In my testing on aarch64 and octeon (both of which I think are strict
> alignment) neither need pullups nor copyups as the mbuf already has enough
> and arphrd is aligned correctly already.
Ah, we asserted too much alignment - indeed,
On 16/02/2021 09:20, Martin Husemann wrote:
On Tue, Feb 16, 2021 at 08:26:40AM +, Roy Marples wrote:
Is that because ARP_HDR_ALIGNMENT is forcing 4 byte alignment?
The KASSERT a few lines below triggerd, we need to be consistent.
For the purposes of using just the header we define I'm
On Tue, Feb 16, 2021 at 08:26:40AM +, Roy Marples wrote:
> Is that because ARP_HDR_ALIGNMENT is forcing 4 byte alignment?
The KASSERT a few lines below triggerd, we need to be consistent.
> For the purposes of using just the header we define I'm pretty sure we can
> use 2 byte alignment and
On 16/02/2021 05:44, Martin Husemann wrote:
Module Name:src
Committed By: martin
Date: Tue Feb 16 05:44:14 UTC 2021
Modified Files:
src/sys/netinet: if_arp.c
Log Message:
Undo previous backout: alignment is needed here.
The reason for the previous backout was a
On Sun, Feb 14, 2021 at 07:46:38PM +, Roy Marples wrote:
> On 13/02/2021 21:34, David Young wrote:
> > On Tue, Feb 09, 2021 at 07:02:32AM +, Roy Marples wrote:
> > > Hi David
> > >
> > > On 03/02/2021 21:45, David Young wrote:
> > > >
> > > > This change looks a little hasty to me.
> > >
On Mon, Feb 15, 2021 at 04:37:15PM +0100, Thomas Klausner wrote:
> Hi!
>
> Thanks for the man pages.
>
> There is none for uselocale(3), which is heavily referenced from
> these, nor do I find a prototype in /usr/include...
> so how does one use these? :)
We don't support uselocale. You use
Hi!
Thanks for the man pages.
There is none for uselocale(3), which is heavily referenced from
these, nor do I find a prototype in /usr/include...
so how does one use these? :)
Thomas
On Mon, Feb 15, 2021 at 09:35:04AM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
On 13/02/2021 21:34, David Young wrote:
On Tue, Feb 09, 2021 at 07:02:32AM +, Roy Marples wrote:
Hi David
On 03/02/2021 21:45, David Young wrote:
This change looks a little hasty to me.
It looks to me like some of these structs were __packed so that
they could be read/written directly
On 13/02/2021 14:19, Jonathan A. Kollasch wrote:
On Sat, Feb 13, 2021 at 07:28:05AM +, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Sat Feb 13 07:28:05 UTC 2021
Modified Files:
src/sys/net: if_ether.h if_ethersubr.c
Log Message:
if_ether: Ensure that
On Tue, Feb 09, 2021 at 07:02:32AM +, Roy Marples wrote:
> Hi David
>
> On 03/02/2021 21:45, David Young wrote:
> >
> > This change looks a little hasty to me.
> >
> > It looks to me like some of these structs were __packed so that
> > they could be read/written directly from/to any offset in
On 13.02.2021 17:20, Valery Ushakov wrote:
Thanks for working on this, but a couple of nitpicks:
On Sat, Feb 13, 2021 at 14:30:37 +, Roland Illig wrote:
In sysinst, the installation screen is indented with tabs. Sysinst uses
msgc, which brings its own text layout engine. This engine
On 13.02.2021 20:00, Valery Ushakov wrote:
On Sat, Feb 13, 2021 at 14:30:37 +, Roland Illig wrote:
Libcurses can be built in 2 modes: with wide character support or
without (-DDISABLE_WCHAR). The test suite only covers the variant with
wide characters. The single-byte variant has to be
On Sat, Feb 13, 2021 at 14:30:37 +, Roland Illig wrote:
> Libcurses can be built in 2 modes: with wide character support or
> without (-DDISABLE_WCHAR). The test suite only covers the variant with
> wide characters. The single-byte variant has to be tested manually.
> Running sysinst with
Thanks for working on this, but a couple of nitpicks:
On Sat, Feb 13, 2021 at 14:30:37 +, Roland Illig wrote:
> In sysinst, the installation screen is indented with tabs. Sysinst uses
> msgc, which brings its own text layout engine. This engine does not use
> addbytes but addch.
[...]
>
On Sat, Feb 13, 2021 at 07:28:05AM +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Sat Feb 13 07:28:05 UTC 2021
>
> Modified Files:
> src/sys/net: if_ether.h if_ethersubr.c
>
> Log Message:
> if_ether: Ensure that ether_header is aligned
>
>
> To
Hi David
On 03/02/2021 21:45, David Young wrote:
>
> This change looks a little hasty to me.
>
> It looks to me like some of these structs were __packed so that
> they could be read/written directly from/to any offset in a packet
> chain using mtod(), which does not pay any mind to the alignment
At Sun, 7 Feb 2021 09:22:39 +,
nia wrote:
> > > -It is called at any time.
> > > +It can be called at any time.
> >
> > The later sounds to me "You(developer of MD driver) can call
> > it at any time". If so, it's incorrect.
>
> Maybe "it can be called by the MI layer at any time" is
On 04/02/2021 20:18, matthew green wrote:
Roy Marples writes:
On 03/02/2021 21:45, David Young wrote:
On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Wed Feb 3 05:51:40 UTC 2021
Modified Files:
src/sys/net:
On Sun, Feb 07, 2021 at 12:43:40PM +0900, Tetsuya Isaki wrote:
> > @@ -175,9 +175,9 @@
> > .Vt audio_format_t
> > structure according to given number
> > .Va afp->index .
> > -If there is no format with given number, return
> > +If there is no format with the given number, return
> > .Er
Hello,
At Sat, 6 Feb 2021 13:55:40 +,
Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Sat Feb 6 13:55:40 UTC 2021
>
> Modified Files:
> src/share/man/man9: audio.9
>
> Log Message:
> Fix various typos, etc
>
>
> To generate a diff of this commit:
> cvs
On Thu, Feb 04, 2021 at 09:07:06PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Thu Feb 4 21:07:06 UTC 2021
>
> Modified Files:
> src/sys/kern: vfs_init.c vfs_subr.c
> src/sys/sys: mount.h
>
> Log Message:
> introduce
Roy Marples writes:
> On 03/02/2021 21:45, David Young wrote:
> > On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote:
> >> Module Name: src
> >> Committed By: roy
> >> Date: Wed Feb 3 05:51:40 UTC 2021
> >>
> >> Modified Files:
> >>src/sys/net: if_arp.h
Hello,
On Fri, 05 Feb 2021 00:12:35 +0900
Tetsuya Isaki wrote:
> At Wed, 3 Feb 2021 13:37:24 -0500,
> Michael wrote:
> > > Committed By: isaki
> > > Date: Wed Feb 3 15:13:49 UTC 2021
> > >
> > > Modified Files:
> > > src/sys/arch/hppa/gsc: harmony.c
> > >
> > > Log Message:
On 03/02/2021 21:45, David Young wrote:
On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Wed Feb 3 05:51:40 UTC 2021
Modified Files:
src/sys/net: if_arp.h if_ether.h if_gre.h
src/sys/netinet: if_ether.h igmp.h
Hello,
At Wed, 3 Feb 2021 13:37:24 -0500,
Michael wrote:
> > Committed By: isaki
> > Date: Wed Feb 3 15:13:49 UTC 2021
> >
> > Modified Files:
> > src/sys/arch/hppa/gsc: harmony.c
> >
> > Log Message:
> > Fix locking against myself.
> > trigger_output will be called
On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Wed Feb 3 05:51:40 UTC 2021
>
> Modified Files:
> src/sys/net: if_arp.h if_ether.h if_gre.h
> src/sys/netinet: if_ether.h igmp.h in.h ip.h ip6.h ip_carp.h ip_icmp.h
>
On 03.02.2021 16:52, Roy Marples wrote:
> But you *have* to interogate the headers in order to work this out.
I noted how this could break. I'm right now not affected by this myself.
Please monitor gnats for reports.
I defer any decisions and discussions (if any) now to others.
Hello,
On Wed, 3 Feb 2021 15:13:49 +
"Tetsuya Isaki" wrote:
> Module Name: src
> Committed By: isaki
> Date: Wed Feb 3 15:13:49 UTC 2021
>
> Modified Files:
> src/sys/arch/hppa/gsc: harmony.c
>
> Log Message:
> Fix locking against myself.
> trigger_output will be called
On 03/02/2021 12:54, Kamil Rytarowski wrote:
This is still a valid usage and ABI breakage for userland. You cannot
blame a user for using system structures and headers that stop working
after an upgrade, at least before at least libc version bump.
For the record, I broke ABI here (it was the
On Wed, Feb 03, 2021 at 11:03:25AM +0100, Kamil Rytarowski wrote:
> On 03.02.2021 06:51, Roy Marples wrote:
> > Module Name:src
> > Committed By: roy
> > Date: Wed Feb 3 05:51:40 UTC 2021
> >
> > Modified Files:
> > src/sys/net: if_arp.h if_ether.h if_gre.h
> >
On 03.02.2021 13:39, Roy Marples wrote:
> On 03/02/2021 10:03, Kamil Rytarowski wrote:
>> On 03.02.2021 06:51, Roy Marples wrote:
>>> Module Name: src
>>> Committed By: roy
>>> Date: Wed Feb 3 05:51:40 UTC 2021
>>>
>>> Modified Files:
>>> src/sys/net: if_arp.h if_ether.h if_gre.h
On 03/02/2021 10:03, Kamil Rytarowski wrote:
On 03.02.2021 06:51, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Wed Feb 3 05:51:40 UTC 2021
Modified Files:
src/sys/net: if_arp.h if_ether.h if_gre.h
src/sys/netinet: if_ether.h igmp.h in.h ip.h ip6.h
On 03/02/2021 08:34, Joerg Sonnenberger wrote:
On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Wed Feb 3 05:51:40 UTC 2021
Modified Files:
src/sys/net: if_arp.h if_ether.h if_gre.h
src/sys/netinet: if_ether.h
On 03.02.2021 06:51, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Wed Feb 3 05:51:40 UTC 2021
>
> Modified Files:
> src/sys/net: if_arp.h if_ether.h if_gre.h
> src/sys/netinet: if_ether.h igmp.h in.h ip.h ip6.h ip_carp.h ip_icmp.h
> ip_mroute.h
On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Wed Feb 3 05:51:40 UTC 2021
>
> Modified Files:
> src/sys/net: if_arp.h if_ether.h if_gre.h
> src/sys/netinet: if_ether.h igmp.h in.h ip.h ip6.h ip_carp.h ip_icmp.h
>
Date:Mon, 1 Feb 2021 17:50:54 +
From:"Jaromir Dolecek"
Message-ID: <20210201175054.112e7f...@cvs.netbsd.org>
| FreeBSD has a similar check, but they return EINVAL instead, feel
| free to adjust if SUS or other standard mandates specific value
Not currently
> On 12. Jul 2020, at 21:05, Jaromir Dolecek wrote:
>
> Module Name: src
> Committed By: jdolecek
> Date: Sun Jul 12 19:05:32 UTC 2020
>
> Modified Files:
> src/sys/dev/pci: if_bnx.c if_bnxvar.h
>
> Log Message:
> enable MSI/MSI-X if supported by adapter
>
> tested MSI-X with
Hi,
I have one question about the following commit.
Why stoeplitz_hash_ip4() and stoeplitz_hash_ip4port() argument types
are different between toeplitz.c and toeplitz.h? They have in_addr_t
and in_port_t argument types in toeplitz.c, howerver uint32_t and
uint16_t in toeplitz.h.
On 2021/01/31
Date:Sun, 31 Jan 2021 18:34:22 +0100
From:Joerg Sonnenberger
Message-ID:
| That makes no sense. Just turn them into a short read, which is
| something users have to deal with anyway.
I'm not sure I agree with that one. If the user's size * nmemb
overflows a
On 31.01.2021 18:34, Joerg Sonnenberger wrote:
> On Sun, Jan 31, 2021 at 05:27:28PM +0100, Kamil Rytarowski wrote:
>> On 31.01.2021 17:18, Jaromir Dolecek wrote:
>>> Module Name:src
>>> Committed By: jdolecek
>>> Date: Sun Jan 31 16:18:22 UTC 2021
>>>
>>> Modified
On Sun, Jan 31, 2021 at 05:27:28PM +0100, Kamil Rytarowski wrote:
> On 31.01.2021 17:18, Jaromir Dolecek wrote:
> > Module Name:src
> > Committed By: jdolecek
> > Date: Sun Jan 31 16:18:22 UTC 2021
> >
> > Modified Files:
> > src/lib/libc/stdio: fread.c
> >
> >
On 31.01.2021 17:18, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Sun Jan 31 16:18:22 UTC 2021
>
> Modified Files:
> src/lib/libc/stdio: fread.c
>
> Log Message:
> for unbuffered I/O arrange for the destination buffer to be filled in one
> go, instead
On 27.01.2021 20:54, Reinoud Zandijk wrote:
Hi,
On Tue, Jan 26, 2021 at 11:44:56PM +, Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Tue Jan 26 23:44:56 UTC 2021
Modified Files:
src/usr.bin/make: parse.c
src/usr.bin/make/unit-tests:
> 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
Hi Reinoud,
Reinoud Zandijk wrote:
> Hi Simon,
>
> On Wed, Jan 27, 2021 at 05:27:01AM +, Simon Burge wrote:
> > Module Name:src
> > Committed By: simonb
> > Date: Wed Jan 27 05:27:01 UTC 2021
> >
> > Modified Files:
> > src/doc: CHANGES
> >
> > Log Message:
Hi Simon,
On Wed, Jan 27, 2021 at 05:27:01AM +, Simon Burge wrote:
> Module Name: src
> Committed By: simonb
> Date: Wed Jan 27 05:27:01 UTC 2021
>
> Modified Files:
> src/doc: CHANGES
>
> Log Message:
> Note support for QEMU "mipssim" emulator.
Is this machine also *able*
Hi,
On Tue, Jan 26, 2021 at 11:44:56PM +, Roland Illig wrote:
> Module Name: src
> Committed By: rillig
> Date: Tue Jan 26 23:44:56 UTC 2021
>
> Modified Files:
> src/usr.bin/make: parse.c
> src/usr.bin/make/unit-tests: include-main.exp include-subsub.mk
>
> Log
On Tue, Jan 26, 2021 at 11:39:52PM +0100, Roland Illig wrote:
> The code of usr.bin/make gets distributed to a wider audience by Simon's
> bmake distribution (http://www.crufty.net/help/sjg/bmake.html), that's
> where the requirement of supporting C89 compilers comes from. At the
> time I
> 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
On Wed, Jan 27, 2021 at 01:00:05 +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Wed Jan 27 01:00:05 UTC 2021
>
> Modified Files:
> src/sys/sys: device.h
>
> Log Message:
> Define a macro to terminate the common usage of device_compatible_entry
>
On 26.01.2021 21:04, Christos Zoulas wrote:
Yes, and I did not push for it for the exact reasons stated below:
There was only a handful of cases and those can be handled with casts or a
macro for now.
I am questioning though the utility of maintaining compatibility with platforms
that
do not
Yes, and I did not push for it for the exact reasons stated below:
There was only a handful of cases and those can be handled with casts or a
macro for now.
I am questioning though the utility of maintaining compatibility with platforms
that
do not support C99 20 years later, vs. using %u and
On 26.01.2021 11:19, Rin Okuyama wrote:
Ping?
I don't think this is correct fix either.
Can you please revert this commit?
Sorry, I didn't get the first mail from Christos back in December,
that's why I didn't take any action.
Why shouldn't the fix I did be correct? I carefully checked the
On Tue, Jan 26, 2021 at 05:51:42PM +0900, Rin Okuyama wrote:
> Hi,
> This seems not correct for me. Is the attached patch OK with you?
Well you spotted a bug indeed int he freeing section. I'll fix and commit it.
Thanks for reporting.
Reinoud
signature.asc
Description: PGP signature
Ping?
I don't think this is correct fix either.
Can you please revert this commit?
Thanks,
rin
On 2020/12/15 7:57, Christos Zoulas wrote:
In article <20201213212746.3cfc3f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Sun Dec
Hi,
On 2021/01/25 0:33, Reinoud Zandijk wrote:
Module Name:src
Committed By: reinoud
Date: Sun Jan 24 15:33:02 UTC 2021
Modified Files:
src/sys/dev/pci: virtio_pci.c
Log Message:
On error unmap the pci_mapreg_map()d regions using bus_space_unmap() as
suggested by jak@
> 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 true.
>
> That's
On 25.01.2021 17:19, Jason Thorpe wrote:
>
>> 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
On Mon, Jan 25, 2021 at 20:28:52 +0300, Valery Ushakov wrote:
> On Mon, Jan 25, 2021 at 08:19:44 -0800, Jason Thorpe wrote:
>
> > > 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
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 true.
That's right, but you could explicitly init a named field, most likely
the one
On Mon, Jan 25, 2021 at 08:19:44 -0800, Jason Thorpe wrote:
> > 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
> 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 25.01.2021 15:20, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Mon Jan 25 14:20:39 UTC 2021
>
> Modified Files:
> src/sys/arch/arm/altera: cycv_clkmgr.c
> src/sys/arch/arm/amlogic: meson_pinctrl.c meson_pwm.c meson_thermal.c
>
> 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
On Sun, Jan 24, 2021 at 09:45:14PM -0800, Jason Thorpe wrote:
>
> > 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
> 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
On Sun, Jan 24, 2021 at 03:34:08PM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sun Jan 24 15:34:08 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
> Log Message:
> Redefining bus_space functions in drivers is a bad idea, and we
> 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
In article <17141.1611452...@splode.eterna.com.au>,
matthew green wrote:
>Christos Zoulas writes:
>> In article <20210123230600.52be160...@jupiter.mumble.net>,
>> Taylor R Campbell wrote:
>> >
>> >Conversely, how do you know whether this hacked-up implementation
>> >which tears the write into
Christos Zoulas writes:
> In article <20210123230600.52be160...@jupiter.mumble.net>,
> Taylor R Campbell wrote:
> >
> >Conversely, how do you know whether this hacked-up implementation
> >which tears the write into two will actually work? Maybe it works for
> >virtio but there are likely other
In article <20210123230600.52be160...@jupiter.mumble.net>,
Taylor R Campbell wrote:
>
>Conversely, how do you know whether this hacked-up implementation
>which tears the write into two will actually work? Maybe it works for
>virtio but there are likely other devices out there for which it will
> Date: Sat, 23 Jan 2021 22:59:22 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article <23974.1611441...@splode.eterna.com.au>,
> matthew green wrote:
> >this seems dangerous to me. we don't define it on
> >some platforms because we can't, so having it faked
> >out here
In article <23974.1611441...@splode.eterna.com.au>,
matthew green wrote:
>"Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Jan 23 20:00:19 UTC 2021
>>
>> Modified Files:
>> src/sys/dev/pci: virtio_pci.c
>>
>> Log Message:
>> Provide
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sat Jan 23 20:00:19 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
> Log Message:
> Provide a generic bus_space_write_8 function that is bi-endian.
this seems dangerous to me. we don't
901 - 1000 of 11274 matches
Mail list logo
