> 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()
>
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
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 23:26
On Mon, Nov 18, 2013 at 11:09 PM, Philip Guenther wrote:
> On Mon, Nov 18, 2013 at 7:16 PM, Eitan Adler 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
> undefined." That's guaranteed by 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
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 d
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.
On Mon, Nov 18, 2013 at 7:16 PM, Eitan Adler 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 pointer to unsig
On 18 Nov 2013, at 11:59 pm, Martin Pieuchot wrote:
> 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
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 the
> On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst 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
> >>
> >
On Mon, Nov 18, 2013 at 3:19 PM, Ted Unangst 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:
>> in
> 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 lik
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 a
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
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
> 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
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 woul
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 @@ voidif_f
> 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.
^^^
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 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
+++ sys/net/pfvar.h
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
+++ sys/netinet/if_eth
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 @@
#inclu
On Mon, Nov 18, 2013 at 11:28:56AM +, Alexey E. Suslikov wrote:
> Martin Pieuchot nolizard.org> writes:
>
> > - case IFT_FDDI:
> > - case IFT_ATM:
> > case IFT_IEEE1394:
>
> any plans for FireWire? :)
>
Nope. :-)
Ken
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 pa
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 manipulate
Martin Pieuchot nolizard.org> writes:
> -1803,8 +1651,12 in6_delmulti(struct in6_multi
*in6m)
> + s = splsoftnet();
> + TAILQ_REMOVE(&ifp->if_maddrlist, &in6m->in6m_ifma, ifma_list);
> + splx(s);
> +
> free(in6m, M_IPMADDR);
> }
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 o
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 wrote:
> > > Is this done right?
> > >
> > > Works here with pppoe(4) for both IPv4 and IPv6.
> > >
> >
> > i think this diff might lack
Martin Pieuchot nolizard.org> writes:
> - case IFT_FDDI:
> - case IFT_ATM:
> case IFT_IEEE1394:
any plans for FireWire? :)
On Mon, Nov 18, 2013 at 3:03 AM, Alexander Bluhm
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 quick on { $ext_
> Date: Mon, 18 Nov 2013 11:26:31 +0100
> From: Stefan Sperling
>
> 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
On 18 November 2013 11:24, Martin Pieuchot 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...
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 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
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
retri
37 matches
Mail list logo
