On 2013/05/10 13:18, Damien Miller wrote:
On Wed, 8 May 2013, Ted Unangst wrote:
On Tue, Apr 30, 2013 at 18:57, Arto Jonsson wrote:
Taken from netbsd with minor modifications. Comments?
I don't think you've received much feedback. I don't know how other
developers feel, but the
On Fri, May 10, 2013 at 08:04:57AM +0100, Stuart Henderson wrote:
If we do use this implementation, then pascal@'s version from 2011 added
some fixes from FreeBSD, http://comments.gmane.org/gmane.os.openbsd.tech/25740
I'll take a closer look at this and freebsd's code later today. There's
one
So this is is one more step in my effort to merge the various code paths
to submit an USB transfer.
This diff gets rid of the two badly named functions: usbd_bulk_transfer()
usbd_intr_transfer() and makes use of the usbd_setup_xfer(9) +
usbd_transfer(9) combination. These functions were badly
Hi,
I'll commit it then, if there are no objections.
On Sat, May 04, 2013 at 14:09 +0200, Sebastian Reitenbach wrote:
On Friday, May 3, 2013 17:16 CEST, Mike Belopuhov m...@belopuhov.com wrote:
hi,
as far as i can tell these functions are not used anymore.
my sparcbook 3gx
On Fri, May 03, 2013 at 16:19 +0200, Mike Belopuhov wrote:
hi,
while looking for the device_unref bugs, i found that
vscsi doesn't check if device_lookup has returned a
valid return value.
ok?
anyone?
diff --git sys/dev/vscsi.c sys/dev/vscsi.c
index 3da371c..db65642 100644
---
Mike,
but it does check in vscsiopen(). Hence no userland program should be
able to call vscsiioctl() for a non-existant device because the open()
already failed. At least that's true as long as vscsi devices can't
disappear during run-time.
Gerhard
On Fri, 10 May 2013 14:44:39 +0200 Mike
On 10 May 2013 14:57, Gerhard Roth gerhard_r...@genua.de wrote:
Mike,
but it does check in vscsiopen(). Hence no userland program should be
able to call vscsiioctl() for a non-existant device because the open()
already failed. At least that's true as long as vscsi devices can't
disappear
On 2013/02/22 12:30, Stuart Henderson wrote:
I thought we already had something for this after the misc@ thread
a few months ago, but clearly not.
Adapted from FreeBSD if_lagg.c r171661 (which includes capability
setting which we already do).
On Fri, May 10, 2013 at 08:04:57AM +0100, Stuart Henderson wrote:
On 2013/05/10 13:18, Damien Miller wrote:
On Wed, 8 May 2013, Ted Unangst wrote:
On Tue, Apr 30, 2013 at 18:57, Arto Jonsson wrote:
Taken from netbsd with minor modifications. Comments?
I don't think you've
On 10 May 2013 16:43, Chris Cappuccio ch...@nmedia.net wrote:
Stuart Henderson [st...@openbsd.org] wrote:
On 2013/02/22 12:30, Stuart Henderson wrote:
I thought we already had something for this after the misc@ thread
a few months ago, but clearly not.
Adapted from FreeBSD if_lagg.c
On 2013/05/10 16:53, Mike Belopuhov wrote:
On 10 May 2013 16:43, Chris Cappuccio ch...@nmedia.net wrote:
Stuart Henderson [st...@openbsd.org] wrote:
On 2013/02/22 12:30, Stuart Henderson wrote:
I thought we already had something for this after the misc@ thread
a few months ago, but
Hi,
the diff is needed - I was running into it quite recently when I was
trying some QinQ/svlan configurations on trunk.
Comments below, otherwise OK
reyk
On Fri, May 10, 2013 at 02:11:28PM +0100, Stuart Henderson wrote:
Index: if_trunk.c
On Fri, May 10, 2013 at 04:53:18PM +0200, Mike Belopuhov wrote:
if (tr-tr_ac.ac_if.if_mtu != ifp-if_mtu) seems wrong. what about people
who want to use trunk between two totally different interfaces for failover?
i think the trunk mtu should simply be the lowest common of the group.
i
Penned by Ted Unangst on 20130504 0:57.40, we have:
| On Sat, May 04, 2013 at 07:26, Martijn van Duren wrote:
| For a lot of cases this isn't a problem. But there are a couple of
| instances where the domain name resolves to something a little to
| generic to be useful to determine it's origin
On Fri, May 10, 2013 at 10:35 -0700, Matthew Dempsky wrote:
On Fri, May 10, 2013 at 6:02 AM, Mike Belopuhov m...@belopuhov.com wrote:
my intention here is very simple: there's a way you should call
device_lookup and everyone has to fulfill it's part of the contract.
all our devices do,
On Fri, May 10, 2013 at 6:02 AM, Mike Belopuhov m...@belopuhov.com wrote:
my intention here is very simple: there's a way you should call
device_lookup and everyone has to fulfill it's part of the contract.
all our devices do, vscsi doesn't. what's the reason for it to be
one of a kind?
I'm
Arto Jonsson ajons...@kapsi.fi writes:
On Fri, May 10, 2013 at 08:04:57AM +0100, Stuart Henderson wrote:
On 2013/05/10 13:18, Damien Miller wrote:
On Wed, 8 May 2013, Ted Unangst wrote:
On Tue, Apr 30, 2013 at 18:57, Arto Jonsson wrote:
Taken from netbsd with minor modifications.
Han Boetes h...@boetes.org writes:
Hi,
Hi (again),
I noticed emacs failed to build after switching to 5.3. I
discussed the matter with the emacs devs and they added some debug
code which is triggered by CFLAGS='-g3 -DUNEXELF_DEBUG' So when
it's building the main binary at Dumping under the
Han Boetes wrote:
I noticed emacs failed to build after switching to 5.3. I
discussed the matter with the emacs devs and they added some
debug code which is triggered by CFLAGS='-g3 -DUNEXELF_DEBUG' So
when it's building the main binary at Dumping under the name
emacs I get this output:
19 matches
Mail list logo
