lsearch(3) is just lfind(3) + append. If we write it that way we
shrink lsearch.c. The third function, linear_base(), is just added
complexity. The indirection buys us nothing.
I don't think we need to keep the historical comment, either.
lsearch(3) is pure computation, it does not set errno:
On Mon, 06 Dec 2021 19:29:55 -0600, Scott Cheloha wrote:
> This?
I think this is fine. OK millert@
- todd
On Mon, Dec 06, 2021 at 08:46:57PM -0600, Scott Cheloha wrote:
> The arguments to printf() here are backwards.
>
> ok?
ok jsg@
>
> Index: uvm_vnode.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
> retrieving revision 1.119
>
The arguments to printf() here are backwards.
ok?
Index: uvm_vnode.c
===
RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.119
diff -u -p -r1.119 uvm_vnode.c
--- uvm_vnode.c 23 Oct 2021 14:42:08 - 1.119
+++
Updated on top of latest source.
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.269
diff -u -p -r1.269 uipc_socket.c
--- sys/kern/uipc_socket.c 11 Nov 2021 16:35:09 -
Scott Cheloha wrote:
> On Mon, Dec 06, 2021 at 03:09:05PM -0700, Theo de Raadt wrote:
> > +* Use memmove(3) instead of memcpy(3), just in case key
> > +* partially overlaps with the end of the array.
> >
> > It isn't a "just in case", as in a possibility.
>
> ?
>
> > It is
On Mon, Dec 06, 2021 at 03:09:05PM -0700, Theo de Raadt wrote:
> +* Use memmove(3) instead of memcpy(3), just in case key
> +* partially overlaps with the end of the array.
>
> It isn't a "just in case", as in a possibility.
?
> It is gauranteed this condition will happen.
I
On Mon, Dec 6, 2021 at 10:30 AM Scott Cheloha
wrote:
> In the moncontrol(3) code we have this fallback function, hertz().
> The idea is to use an undocumented side effect of setitimer(2) to
> determine the width of the hardclock(9) tick.
>
> hertz() has a number of problems:
>
> So, I want to
+* Use memmove(3) instead of memcpy(3), just in case key
+* partially overlaps with the end of the array.
It isn't a "just in case", as in a possibility.
It is gauranteed this condition will happen.
I don't like how these conditions are described as odd-cases, that
isn't how
On Mon, Dec 06, 2021 at 01:47:52PM -0700, Todd C. Miller wrote:
> On Mon, 06 Dec 2021 09:03:43 -0600, Scott Cheloha wrote:
>
> > In lsearch(3), the key is allowed to overlap with the last element in
> > base. We need to memmove(3), not memcpy(3), or we could corrupt the
> > key in that edge
> Date: Mon, 6 Dec 2021 21:45:03 +0100
> From: Anton Lindqvist
>
> On Mon, Dec 06, 2021 at 09:23:45PM +0100, Mark Kettenis wrote:
> > > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > > From: Patrick Wildt
> > >
> > > Hi,
> > >
> > > On one machine I had the pleasure of having to try and use the
> >
On Mon, Dec 06, 2021 at 08:35:15PM +0100, Mark Kettenis wrote:
> > Date: Sun, 5 Dec 2021 18:01:04 -0600
> > From: Scott Cheloha
> >
> > Two things in sys_kbind() need an explicit kernel lock. First,
> > sigexit(). Second, uvm_map_extract(), because the following call
> > chain panics without
These com devices are normally edge interrupt, which means they are
sometimes shared. Shared isn't ideal, but it often works.
So an acpi driver is now participating in edge shared devices.
Let's imagine a com2 is mistakenly wired to irq 3, but not listed by
acpi, while com0 is at irq 3 and
Mark Kettenis wrote:
> What we really want is that these "com* at acpi?" ports replace the
> "com* at isa?" ports. These are the "standard" COM1-4 ports after
> all. So the solution we came up with was to add:
>
> com0 at acpi?
> com1 at acpi?
> com2 at acpi?
> com3 at acpi?
> com* at acpi?
On Mon, 06 Dec 2021 09:03:43 -0600, Scott Cheloha wrote:
> In lsearch(3), the key is allowed to overlap with the last element in
> base. We need to memmove(3), not memcpy(3), or we could corrupt the
> key in that edge case.
OK, but does this deserve a comment so to that effect to prevent
On Mon, Dec 06, 2021 at 09:23:45PM +0100, Mark Kettenis wrote:
> > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > From: Patrick Wildt
> >
> > Hi,
> >
> > On one machine I had the pleasure of having to try and use the
> > Serial-over-LAN feature which shows up as just another com(4)
> > device.
> Date: Mon, 6 Dec 2021 21:26:11 +0100
> From: Patrick Wildt
>
> Am Mon, Dec 06, 2021 at 09:23:45PM +0100 schrieb Mark Kettenis:
> > > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > > From: Patrick Wildt
> > >
> > > Hi,
> > >
> > > On one machine I had the pleasure of having to try and use the
> >
> From: "Theo de Raadt"
> Date: Mon, 06 Dec 2021 13:17:37 -0700
>
> What comN does this attach as?
>
> The isa ones are are hard-wired:
>
> com0at isa? port 0x3f8 irq 4# standard PC serial ports
> com1at isa? port 0x2f8 irq 3
> com2at isa? port 0x3e8 irq 5
> com3at isa?
Errata patch for rpki-client has been released for OpenBSD 6.9.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata69.html
Stuart Henderson wrote:
> > +#ifdef __amd64__
> > + /* Ignore com(4) at isa(4) */
> > + if (aaa->aaa_addr[0] == 0x3f8 || aaa->aaa_addr[0] == 0x2f8 ||
> > + aaa->aaa_addr[0] == 0x3e8 || aaa->aaa_addr[0] == 0x2e8)
> > + return 0;
> > +#endif
>
> One of the benefits of using
Am Mon, Dec 06, 2021 at 09:23:45PM +0100 schrieb Mark Kettenis:
> > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > From: Patrick Wildt
> >
> > Hi,
> >
> > On one machine I had the pleasure of having to try and use the
> > Serial-over-LAN feature which shows up as just another com(4)
> > device.
On 2021/12/06 21:08, Patrick Wildt wrote:
> Hi,
>
> On one machine I had the pleasure of having to try and use the
> Serial-over-LAN feature which shows up as just another com(4)
> device. Instead of having to manually add a com(4) at isa(4)
> I figured it would be nicer to have them attach via
> Date: Mon, 6 Dec 2021 21:08:04 +0100
> From: Patrick Wildt
>
> Hi,
>
> On one machine I had the pleasure of having to try and use the
> Serial-over-LAN feature which shows up as just another com(4)
> device. Instead of having to manually add a com(4) at isa(4)
> I figured it would be nicer
What comN does this attach as?
The isa ones are are hard-wired:
com0at isa? port 0x3f8 irq 4# standard PC serial ports
com1at isa? port 0x2f8 irq 3
com2at isa? port 0x3e8 irq 5
com3at isa? disable port 0x2e8 irq 9 # (conflicts with some video cards)
So they will consume
Hi,
On one machine I had the pleasure of having to try and use the
Serial-over-LAN feature which shows up as just another com(4)
device. Instead of having to manually add a com(4) at isa(4)
I figured it would be nicer to have them attach via ACPI. At
least on that machine, the SOL definitely
> Date: Sun, 5 Dec 2021 18:01:04 -0600
> From: Scott Cheloha
>
> Two things in sys_kbind() need an explicit kernel lock. First,
> sigexit(). Second, uvm_map_extract(), because the following call
> chain panics without it:
>
> panic
> assert
> uvn_reference
> uvm_mapent_clone
> uum_map_extract
In the moncontrol(3) code we have this fallback function, hertz().
The idea is to use an undocumented side effect of setitimer(2) to
determine the width of the hardclock(9) tick.
hertz() has a number of problems:
1. Per the setitimer(2) standard, the value of it_interval is ignored
if
This patch adjusts the EVFILT_EXCEPT code of sockets and FIFOs so that
it would raise the HUP condition only when the channel has been closed
from both sides. This should match better with the POLLHUP case of
soo_poll() and fifo_poll().
The "poll index ... unclaimed" error seen by some was
This adds EVFILT_EXCEPT handler for pipes. It is a subset of
EVFILT_READ; it triggers on EOF only. This captures the POLLHUP
condition of pipe_poll(), used with select(2)'s exceptfds and when
poll(2) has events without (POLLIN | POLLRDNORM | POLLOUT | POLLWRNORM).
OK?
Index: kern/sys_pipe.c
Ping
On Sat, Nov 27, 2021 at 09:36:32PM +0300, Mikhail wrote:
> While fiddling with ehci.c and fighting with urndis I noticed that most
> of the debugging printf's use explicit names, which is inconvenient for
> grep'ing. Also, couple of items used wrong function names
> (ehci_check_intr instead
In lsearch(3), the key is allowed to overlap with the last element in
base. We need to memmove(3), not memcpy(3), or we could corrupt the
key in that edge case.
ok?
Index: lsearch.c
===
RCS file:
On Sat, Dec 04, 2021 at 10:41:02AM +0100, Hrvoje Popovski wrote:
> r620-2# uvm_fault(0x8229d4e0, 0x137, 0, 2) -> e
> kernel: page fault trap, code=0
> Stopped at ipsp_spd_lookup+0xa2f: movq%rax,0(%rcx)
> TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> 419237 67407
On Mon, Dec 06, 2021 at 10:07:47AM +, Stuart Henderson wrote:
> On 2021/12/05 19:22, Yury Shefer wrote:
> > Hi all,
> >
> > I have quad-port Intel ET2 NIC based on 82576[1] controller. The manual
> > says that hardware VLAN tagging should be supported but ifconfig output
> > shows VLAN_MTU
On 2021/12/05 19:22, Yury Shefer wrote:
> Hi all,
>
> I have quad-port Intel ET2 NIC based on 82576[1] controller. The manual
> says that hardware VLAN tagging should be supported but ifconfig output
> shows VLAN_MTU only in hwfeatures on OpenBSD 7.0. How do I check if 802.1Q
> tagging is
On 6.12.2021. 4:22, Yury Shefer wrote:
> Hi all,
>
> I have quad-port Intel ET2 NIC based on 82576[1] controller. The manual
> says that hardware VLAN tagging should be supported but ifconfig output
> shows VLAN_MTU only in hwfeatures on OpenBSD 7.0. How do I check if 802.1Q
> tagging is
35 matches
Mail list logo
