On 2016/06/07 21:49, Vincent Gross wrote:
>
> It's how henning@ set things up when integrating the new queuing mechanism.
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_mbuf.c#rev1.160
>
> > Is there any use for this apart for vlan(4) interfaces?
>
> AFAICT, no.
My understanding
Le Tue, 7 Jun 2016 10:48:22 +0200,
Martin Pieuchot a écrit :
> On 06/06/16(Mon) 23:52, Vincent Gross wrote:
> > On Mon, 6 Jun 2016 17:33:36 +0100
> > Stuart Henderson wrote:
> >
> > > On 2016/06/06 16:15, Vincent Gross wrote:
> > > > When sending ARP requests, or when writing to a bpf handl
Hi Gerhard,
Gerhard Roth wrote on Tue, Jun 07, 2016 at 02:39:42PM +0200:
> On Tue, 7 Jun 2016 13:08:49 +0200 Martin Pieuchot wrote:
>> On 07/06/16(Tue) 11:53, Gerhard Roth wrote:
>>> On Mon, 6 Jun 2016 10:30:11 +0200 Martin Pieuchot wrote:
Any reason for using a different license in docume
> Martin Natano wrote:
> > It is time for the lockmgr() api to die. The api is only used by
> > filesystems, where it is a trivial change to use rrw locks instead. All
> > it needs is LK_* defines for the RW_* flags. (See the sys/lock.h hunk in
> > the diff below.)
> >
> > The ffs regress tests di
Martin Natano wrote:
> It is time for the lockmgr() api to die. The api is only used by
> filesystems, where it is a trivial change to use rrw locks instead. All
> it needs is LK_* defines for the RW_* flags. (See the sys/lock.h hunk in
> the diff below.)
>
> The ffs regress tests display the same
On 2016/06/07 14:39, Gerhard Roth wrote:
> > > Now I get an IP address from my provider, I want something like this:
> > >
> > > inet 10.75.178.41 --> 10.75.178.42 netmask 0xfffc
> > >
> > > But if I used SIOCAIFADDR I would get this instead:
> > >
> > > inet 0.0.0.1 --> 0.0.0.2 netmask
On Tue, 7 Jun 2016 13:08:49 +0200 Martin Pieuchot wrote:
> On 07/06/16(Tue) 11:53, Gerhard Roth wrote:
> > On Mon, 6 Jun 2016 10:30:11 +0200 Martin Pieuchot wrote:
> > > On 01/06/16(Wed) 17:20, Gerhard Roth wrote:
> > > Any reason for using a different license in documentation an code?
> >
> > D
> On 2 Jun 2016, at 4:28 AM, Theo de Raadt wrote:
>
>> As I said, we could still change the name of the interface to 'ubm'
>> while keeping 'umbim' as the name of the driver.
>
> No, I don't understand the proposal. I think it should be ubm
> throughout, or I am threatening to rename ix(4) to
On 07/06/16(Tue) 11:53, Gerhard Roth wrote:
> On Mon, 6 Jun 2016 10:30:11 +0200 Martin Pieuchot wrote:
> > On 01/06/16(Wed) 17:20, Gerhard Roth wrote:
> > Any reason for using a different license in documentation an code?
>
> Different in what sense? Which paragraph do you mean?
This is a BSD 2-
Came across an incorrect comment in httpd(8) explaining memory
allocation. Comment claims that 5 times the source memory needs to
be allocated if source consists solely of "<" and ">", but those
characters expand to four bytes ("&[g/l]t;"). "&" is the reason that
5 times the memory is required ("&"
Came across an incorrect comment in httpd(8) explaining memory
allocation. Comment claims that 5 times the source memory needs to
be allocated if source consists solely of "<" and ">", but those
characters expand to four bytes ("&[g/l]t;"). "&" is the reason that
5 times the memory is required ("&"
On Mon, 6 Jun 2016 10:30:11 +0200 Martin Pieuchot wrote:
> On 01/06/16(Wed) 17:20, Gerhard Roth wrote:
> > [...]
> > Thanks for all the feedback.
>
> More comments inline.
Replies too.
>
> > Index: sbin/ifconfig/ifconfig.c
> > =
Not used, not built, so can just be deleted. Diff below.
Reduces the diff between i386 and amd64 bootblocks.
Thanks
Tom
Index: sys/arch/i386/stand/libsa/cpuprobe.c
===
RCS file: sys/arch/i386/stand/libsa/cpuprobe.c
diff -N sys/ar
As per subject, a couple of empty loop bodies in the i396 and amd64 boot blocks.
Diff below.
Tom
Index: sys/arch/amd64/stand/libsa/biosdev.c
===
RCS file: /home/OpenBSD/cvs/src/sys/arch/amd64/stand/libsa/biosdev.c,v
retrieving revi
On 06/06/16(Mon) 17:14, Jonathan Matthew wrote:
> We've finally got srp and art to the point where we can use srp to manage the
> internal links in the art data structures. This allows us to do route lookups
> without holding any locks, which is kind of nice.
It's awesome!
> As we're not doing u
On 06/06/16(Mon) 23:52, Vincent Gross wrote:
> On Mon, 6 Jun 2016 17:33:36 +0100
> Stuart Henderson wrote:
>
> > On 2016/06/06 16:15, Vincent Gross wrote:
> > > When sending ARP requests, or when writing to a bpf handle (as when
> > > sending DHCP Discover), we bypass pf(4) so we have no way to d
Just noticed this typo in tcp_input.c
G
Index: tcp_input.c
===
RCS file: /cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.318
diff -u -p -u -p -r1.318 tcp_input.c
--- tcp_input.c 31 Mar 2016 13:11:14 - 1.318
+++ tcp
On Sun, May 29, 2016 at 10:55:48PM +0200, Theo Buehler wrote:
> The readlabel() function in disklabel() does two things: it reads the
> disklabel from the device using a ioctl() and then parses it into some
> strings. We can't pledge beforehand since we have no way of knowing the
> file we process
it would be nice to have splraise as an MI api within the kernel
so it could be used in some per cpu data structures. at the moment
the only way to use the ipl passed to such things is to use mutexes,
but then whats the point of having a per cpu data structure if
you're guaranteed to not content wi
19 matches
Mail list logo
