Since we don't support any FDDI or ATM interfaces anymore, remove some
special cases for such interface types in our kernel.
ok?
Index: arch//amd64/amd64/autoconf.c
===
RCS file: /home/ncvs/src/sys/arch/amd64/amd64/autoconf.c,v
On Mon, Nov 18, 2013 at 01:22:20AM +0200, ja...@cieti.lv wrote:
I tried this diff and at least one thing changed -- neverball now works
(previously it immediately hung the GPU on start). There is still corruption
and GPU hanging in chromium. There is corruption in mplayer -vo gl too (and
it is
Diff below changes the way protocol multicast addresses are linked to
an interface.
Right now they are added to a list attached to the first protocol
address of an interface. That makes this address descriptor and
its position in the global list special. Plus in the IPv6 case,
a special kludge
On 18 November 2013 11:24, Martin Pieuchot mpieuc...@nolizard.org wrote:
Since we don't support any FDDI or ATM interfaces anymore, remove some
special cases for such interface types in our kernel.
ok?
OK. looks like there's more stuff that can die in the fire...
Date: Mon, 18 Nov 2013 11:26:31 +0100
From: Stefan Sperling s...@openbsd.org
On Mon, Nov 18, 2013 at 01:22:20AM +0200, ja...@cieti.lv wrote:
I tried this diff and at least one thing changed -- neverball now works
(previously it immediately hung the GPU on start). There is still corruption
On Mon, Nov 18, 2013 at 3:03 AM, Alexander Bluhm
alexander.bl...@gmx.net wrote:
On Thu, Nov 14, 2013 at 12:03:21AM +0200, Alexey Suslikov wrote:
This is on 5.4-stable. vlan is only used to see what resulting prio is.
#match on { $int_if } inet proto icmp all icmp-type echoreq set prio 5
pass
Martin Pieuchot mpieuchot at nolizard.org writes:
- case IFT_FDDI:
- case IFT_ATM:
case IFT_IEEE1394:
any plans for FireWire? :)
On 15/11/13(Fri) 15:45, Stefan Sperling wrote:
On Fri, Nov 15, 2013 at 03:20:48PM +0100, Mike Belopuhov wrote:
On 15 November 2013 15:13, Stefan Sperling s...@openbsd.org wrote:
Is this done right?
Works here with pppoe(4) for both IPv4 and IPv6.
i think this diff might lack
On Mon, Nov 18, 2013 at 12:37:53PM +0100, Martin Pieuchot wrote:
Even if right now calling task_del() is enough, do you know if there's
an easy way to convert this code without putting the task storage in
the chunk of memory it manipulates? In other words having the struct
task outside of the
Martin Pieuchot mpieuchot at nolizard.org writes:
at at -1803,8 +1651,12 at at in6_delmulti(struct in6_multi
*in6m)
snip
+ s = splsoftnet();
+ TAILQ_REMOVE(ifp-if_maddrlist, in6m-in6m_ifma, ifma_list);
+ splx(s);
+
free(in6m,
On 18/11/13(Mon) 13:35, Stefan Sperling wrote:
On Mon, Nov 18, 2013 at 12:37:53PM +0100, Martin Pieuchot wrote:
Even if right now calling task_del() is enough, do you know if there's
an easy way to convert this code without putting the task storage in
the chunk of memory it manipulates? In
On Sat, Nov 16, 2013 at 10:42:05AM +0100, Markus Hennecke wrote:
On Sat, 9 Nov 2013, Jonathan Gray wrote:
This adds the initial bits for the i217/i218 PHY and the
Lynx Point PCH found in Haswell systems.
Doesn't include the new workarounds yet and follows
the pch2/82579 paths for now
On Mon, Nov 18, 2013 at 11:28:56AM +, Alexey E. Suslikov wrote:
Martin Pieuchot mpieuchot at nolizard.org writes:
- case IFT_FDDI:
- case IFT_ATM:
case IFT_IEEE1394:
any plans for FireWire? :)
Nope. :-)
Ken
This guys rely on the fact that if.h includes queue.h, but they
shouldn't really since lists are needed by the struct ifnet only.
OK?
diff --git sbin/dhclient/dhcpd.h sbin/dhclient/dhcpd.h
index 53625fb..c03af36 100644
--- sbin/dhclient/dhcpd.h
+++ sbin/dhclient/dhcpd.h
@@ -43,10 +43,11 @@
This diff hides a bunch of structures (namely arpcom, llinfo_arp,
ethernet multicast macros along the way, and in_ifaddr the same
way in6_ifaddr is hidden).
OK?
diff --git sys/netinet/if_ether.h sys/netinet/if_ether.h
index 9ef9c12..459c3fa 100644
--- sys/netinet/if_ether.h
+++
pfctl shares some structures (namely pfi_kif) with the kernel but
doesn't use the ifnet pointer so it gets a bunch of forward
declarations for ifnet and interface group structures.
OK?
diff --git sys/net/pfvar.h sys/net/pfvar.h
index 37f61e4..a05fc49 100644
--- sys/net/pfvar.h
+++
This diff splits kernel visible parts away from if.h into a separate
header if_var.h. As a compatibility goo for the kernel if.h will
also include if_var.h under _KERNEL. The benefit of going this way
is that we don't need to define _KERNEL in the netstat friends
(a tradeoff is that they will
It's not really surprising that your GM45-based system has a lot of
these issues. Neither jsg@ nor I have access to this hardware. If
somebody has a laptop with this chipset that they're willing to donate
and ship to Australia or the Netherlands, please contact us.
As promised here's a take on hiding ifnet via _KERNEL. This looks
a bit simpler. I've tried not to toss things around that much and
have only moved 'ifqueue'.
diff --git sys/net/if.h sys/net/if.h
index b7d1b3c..9a14117 100644
--- sys/net/if.h
+++ sys/net/if.h
@@ -58,16 +58,15 @@ void
Use Case
I have several headless computers. Their only source of randomness is from the
network. I also have a hardware true random number generator on another
computer. I would like the headless computers to be able to access truly
random numbers from a server - at the kernel level.
I
I would like the headless computers to be able to access
truly random numbers from a server - at the kernel level.
In addition, can a standard be developed and install scripts modified so that
during the install, the install script obtains a bunch of truly random numbers
from a server, to be
I prefer something this model of handling the situation, as long as
the ports tree software handles it well. (But then again, the other
way of doing it will cause effects there as well..)
As promised here's a take on hiding ifnet via _KERNEL. This looks
a bit simpler. I've tried not to toss
Check out /etc/rc, and look for random_seed() and writes into /dev/arandom
On 2013 Nov 18 (Mon) at 19:23:55 + (+), Hendrickson, Kenneth wrote:
:Use Case
:
:I have several headless computers. Their only source of randomness is from
the network. I also have a hardware true random number
On Mon, Nov 18, 2013 at 07:23:55PM +, Hendrickson, Kenneth wrote:
Use Case
I have several headless computers. Their only source of randomness is from
the network. I also have a hardware true random number generator on another
computer. I would like the headless computers to be able
I would like a standard, built into the OS, so I get this improved
source of randomness right from the very first install.
You do get that already. It is not as bad as you might think.
Basically the install script dumps 64K of its own randomness to the
filesystem for the first boot, just like
On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst t...@tedunangst.com wrote:
On Mon, Nov 18, 2013 at 16:10, Ted Unangst wrote:
CVSROOT: /cvs
Module name: src
Changes by: t...@cvs.openbsd.org2013/11/18 16:10:48
Modified files:
lib/librthread : rthread.h rthread_sem.c
Log message:
On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst t...@tedunangst.com wrote:
On Mon, Nov 18, 2013 at 16:10, Ted Unangst wrote:
CVSROOT: /cvs
Module name: src
Changes by: t...@cvs.openbsd.org2013/11/18 16:10:48
Modified files:
lib/librthread : rthread.h rthread_sem.c
Log
Hi all,
clang gives a warning when building fmt(1):
fmt.c:400:35: warning: passing 'char *' to parameter of type 'const
unsigned char *' converts between pointers to integer types with
different sign
might_be_header takes a pointer to unsigned char. However there is no
reason for this to be
On Mon, Nov 18, 2013 at 7:16 PM, Eitan Adler li...@eitanadler.com wrote:
clang gives a warning when building fmt(1):
fmt.c:400:35: warning: passing 'char *' to parameter of type 'const
unsigned char *' converts between pointers to integer types with
different sign
might_be_header takes a
On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
btw, no library version change because the function stubs already
existed.
Hmm, since this is actually offering new functionality (by sem_open()
and friends no longer always failing), I think it a minor bump would
be appropriate.
this one is for hd(4) on hp300s. again, i cant compile and therefore cant test.
anyone able to compile this for me? does anyone have such hardware?
On Sun, Nov 03, 2013 at 09:30:56AM +1000, David Gwynne wrote:
once upon a time pretty much all block storage was on spinning disks, so all
the
this one is for xy(4) on sparc. again, i cant test, so if anyone
could do that for me it would be appreciated.
does anyone have one of these?
Index: xy.c
===
RCS file: /cvs/src/sys/arch/sparc/dev/xy.c,v
retrieving revision 1.57
diff
On Mon, Nov 18, 2013 at 11:09 PM, Philip Guenther guent...@gmail.com wrote:
On Mon, Nov 18, 2013 at 7:16 PM, Eitan Adler li...@eitanadler.com wrote:
The argument passed to isupper must be The argument to isupper() must
be EOF or representable as an unsigned char; otherwise, the result is
and here's the last one, the hdc stuff on vax.
can anyone compile this? test?
Index: hdc9224.c
===
RCS file: /cvs/src/sys/arch/vax/vsa/hdc9224.c,v
retrieving revision 1.41
diff -u -p -r1.41 hdc9224.c
--- hdc9224.c 14 Oct 2013
On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
btw, no library version change because the function stubs already
existed.
Hmm, since this is actually offering new functionality (by sem_open()
and friends no longer
On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
btw, no library version change because the function stubs already
existed.
Hmm, since this is actually offering new functionality (by sem_open()
and friends no
36 matches
Mail list logo
