On Thu, Jun 28, 2012 at 12:40:57PM -0600, Nick Bender wrote:
> On Thu, Jun 28, 2012 at 12:29 PM, Otto Moerbeek wrote:
> > On Thu, Jun 28, 2012 at 11:00:24AM -0600, Nick Bender wrote:
> >>
> >>
> >> TCL? BSD, small, fast, been around forever, C like syntax. In base
> >> would be awesome...
> >>
>
This diff adds support for the Winbond W83627UHG chip, as found on the
Lanner FW-7539 appliance. This diff was ported from DragonFly BSD:
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/245ec76bc1613b22cf282526fa9931e4c16e4237
Here is the "sysctl hw.sensors" output on that Lanner applian
On Thu, Jun 28, 2012 at 11:44:36PM -0300, Christiano F. Haesbaert wrote:
> Although the idea for using -k with -u is a good one, I don't think
> it's necessary, I for one think we should change semantics as the
> first mail suggested.
>
> The only real for using connected UDP sockets is to get the
Although the idea for using -k with -u is a good one, I don't think
it's necessary, I for one think we should change semantics as the
first mail suggested.
The only real for using connected UDP sockets is to get the ICMP async
errors at the socket level, ICMP port unreachable mainly.
I see no rea
This looks good to me, can I get another ok ?
On Sun, Jun 24, 2012 at 07:07:29AM -0400, Ricky Zhou wrote:
> On 2012-06-16 02:37:27 PM, Christiano F. Haesbaert wrote:
> > I guess so, I don't use nc too often but it sounds reasonable to me,
> > your code has a few notes though, please check inline.
On Thu, Jun 28, 2012 at 15:07, Jérémie Courrèges-Anglas wrote:
>> Hi,
>> +
>> +typedef void *HMODULE;
>> +typedef void (*FARPROC)();
>> +#define SUN_DL
>
> Hmmm.
>
>> +#include
>> +
>> +#if defined(SUN_DL)
>
> Huh? 8)
old code is old. :) looks like jasper un-ifdeffed some win32 code,
leaving
It looks like arm and sh are broken too. I've added a regress test to
/usr/src/regress/sys/kern/sigpending if anyone wants to try tackling
one or more of these broken implementations.
On Thu, Jun 28, 2012 at 5:10 PM, Matthew Dempsky wrote:
> On Thu, Jun 28, 2012 at 5:09 PM, Matthew Dempsky
wrot
On Thu, Jun 28, 2012 at 5:09 PM, Matthew Dempsky wrote:
> So the sigpending() system call returns the pending signals as an int
> value via register, but then the libc stub is supposed to take care of
> storing this as appropriate.
>
> If you look at libc/arch/amd64/sys/sigreturn.S, you'll notice
So the sigpending() system call returns the pending signals as an int
value via register, but then the libc stub is supposed to take care of
storing this as appropriate.
If you look at libc/arch/amd64/sys/sigreturn.S, you'll notice there's
some followup assembly code for this. It looks like the a
I'm doing some test runs with Perl 5.16 for Andrew Fresh and seeing
a signal dispatch-related test failure on macppc
kern.version=OpenBSD 5.2-beta (GENERIC.MP) #198: Sat Jun 23 11:30:52 MDT 2012
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP
t/op/sigdispatch ..
On Fri, Jun 29, 2012 at 12:09 AM, Christian Weisgerber
wrote:
> Is there a particular reason we only support AES-128-CTR ("AESCTR")
> with isakmpd(8), but not the 192- and 256-bit variants like we do
> for AES-CBC and AES-GCM?
>
> If not, and I assume it's just a historic oversight, how about this
Is there a particular reason we only support AES-128-CTR ("AESCTR")
with isakmpd(8), but not the 192- and 256-bit variants like we do
for AES-CBC and AES-GCM?
If not, and I assume it's just a historic oversight, how about this?
Adds AES-{128,192,256}-CTR to ipsecctl(8) and isakmpd(8).
There is no
Doc :
<>
Want to do something like
<>
or
<>
Read Code :
found, in if_bridge.c (following SIOCBRDGARL from ifconfig)
<<
bcopy(&req->ifbr_src, &n->brl_src, sizeof(struct ether_addr));
bcopy(&req->ifbr_dst, &n->brl_dst, sizeof(struct ether_addr));
>>
Search for usage of the (documented) field
<<
fi
On Thu, Jun 28, 2012 at 09:55:57AM +0100, Stuart Henderson wrote:
[...]
> # route add -inet6 ff55::1/96 ::1
> add net ff55::1/96: gateway ::1
>
> # route delete -inet6 ff55::1/96
> route: writing to routing socket: No such process
> delete net ff55::1/96: not in table
>
> # route delete -inet6 ff
On Thu, Jun 28, 2012 at 10:05:49PM +0500, Mark Lumsden wrote:
> > > I'd be a lot happier voicing an opinion in support of something like this
> > > if I also saw diffs and interest in *using* them
> > > to extend functionality later or replace some things easier to do with
> > > scheme to make the
On Thu, Jun 28, 2012 at 12:29 PM, Otto Moerbeek wrote:
> On Thu, Jun 28, 2012 at 11:00:24AM -0600, Nick Bender wrote:
>>
>>
>> TCL? BSD, small, fast, been around forever, C like syntax. In base
>> would be awesome...
>>
>>
>
> How can a language where everything is a string be good?
>
> -
On Thu, Jun 28, 2012 at 11:00:24AM -0600, Nick Bender wrote:
> On Thu, Jun 28, 2012 at 9:16 AM, Ted Unangst wrote:
> > Integration is one of the goals. ?I can't predict what extensions you
> > may want to write. ?I mean, mg already reads a .mg file. ?If we knew
> > what people were going to put i
Hi,
I have the weird scenario when I try to tftp a file from a remote tftpd that's
also openbsd that my pf doesn't keep a state open. This is something I need
to fix, however I found this in the logs on the remote tftpd and it's
misleading:
Jun 28 14:03:21 hostname tftpd[2506]: recv: Connection
> > I'd be a lot happier voicing an opinion in support of something like this
> > if I also saw diffs and interest in *using* them
> > to extend functionality later or replace some things easier to do with
> > scheme to make the code simpler - something kjell was alluding to.
>
> I think we can wo
On Thu, Jun 28, 2012 at 9:16 AM, Ted Unangst wrote:
> Integration is one of the goals. I can't predict what extensions you
> may want to write. I mean, mg already reads a .mg file. If we knew
> what people were going to put in their .mg files, we could just hard
> code it in the program and cut
On Thu, Jun 28, 2012 at 10:12:38AM -0400, Ted Unangst wrote:
> On Thu, Jun 28, 2012 at 15:21, Jasper Lievisse Adriaanse wrote:
> > On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote:
>
> >> 2. I should point out that all of mg (other than theo.c) is currently
> >> PUBLIC DOMAIN, not mer
I think the massive mg user base can handle a single flavor. :)
On Thu, Jun 28, 2012 at 11:20 AM, Eichert, Diana wrote:
> On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote:
>
> > 2. I should point out that all of mg (other than theo.c) is currently
> > PUBLIC DOMAIN, not merely BSD,
On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote:
> 2. I should point out that all of mg (other than theo.c) is currently
> PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise.
> Please be pedantic about including licenses.
I'm no developer, but why not
On Thu, Jun 28, 2012 at 08:09, Bob Beck wrote:
> I'd be a lot happier voicing an opinion in support of something like this
> if I also saw diffs and interest in *using* them
> to extend functionality later or replace some things easier to do with
> scheme to make the code simpler - something kjell
On Thu, Jun 28, 2012 at 16:07 +0200, Peter Hessler wrote:
> So we have been running with this diff in the office, and it is working
> well for us.
>
>
> bnx0 at pci7 dev 0 function 0 "Broadcom BCM5709" rev 0x20: apic 0 int 6
> bnx0: address 1c:c1:de:e4:5e:b0
> brgphy0 at bnx0 phy 1: BCM5709 10/10
On Thu, Jun 28, 2012 at 15:21, Jasper Lievisse Adriaanse wrote:
> On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote:
>> 2. I should point out that all of mg (other than theo.c) is currently
>> PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise.
>> Please be peda
I don't want to be in the business of adding 20 different interpreters
> to base. If I did, it'd be lua first by a mile.
>
> That said, tinyscheme is designed to be directly embedded. If it
> turns out people are dying to add scheme support to top and systat, we
> can talk about a shared library,
So we have been running with this diff in the office, and it is working
well for us.
bnx0 at pci7 dev 0 function 0 "Broadcom BCM5709" rev 0x20: apic 0 int 6
bnx0: address 1c:c1:de:e4:5e:b0
brgphy0 at bnx0 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
As a side note, having TXPAUSE and RXPAUSE enab
On Thu, Jun 28, 2012 at 15:07, Jérémie Courrèges-Anglas wrote:
> If the licence seems ok, why not just pull a complete tinyscheme instance,
> that would then be usable from other applications? (tinyscheme doesn't
seem
> to
> be in ports).
I don't want to be in the business of adding 20 different
On Thu, Jun 28, 2012 at 08:35:18AM -0400, Kjell Wooding wrote:
> Thoughts, since we have been down this road before.
>
> 1. You can remap keys, in your ~/.mg file
>
> 2. I should point out that all of mg (other than theo.c) is currently
> PUBLIC DOMAIN, not merely BSD, so this change is significa
> Hi,
Hi.
> Here is an updated diff for mg with tinyscheme integration. It's based on
> tedu's original diff with various tweaks and changes. For those worried
about
> mg being too bloated, rest assured, it's still small and lean and a big
part
> smaller than vi ;-)
> It's not fully possible to t
> I'm all for adding support for scripting into mg, though I would be tempted
> to rip out all nonessential functionality first (ng? ;) and add it back via
> the scripting language. I would think the goal should be to make mg
> significantly *smaller* any such change
>
Could you clarify what you
Thoughts, since we have been down this road before.
1. You can remap keys, in your ~/.mg file
2. I should point out that all of mg (other than theo.c) is currently
PUBLIC DOMAIN, not merely BSD, so this change is significant, license-wise.
Please be pedantic about including licenses.
3. Why sche
If Jasper is going to take care of it, why not :-) ?
I'd like to get the ability to remap keys, without hacking src.
(As an mg user)
On Thu, Jun 28, 2012 at 2:06 PM, Mark Lumsden wrote:
>> Here is an updated diff for mg with tinyscheme integration. It's based on
>> tedu's original diff with var
> Here is an updated diff for mg with tinyscheme integration. It's based on
> tedu's original diff with various tweaks and changes. For those worried about
> mg being too bloated, rest assured, it's still small and lean and a big part
> smaller than vi ;-)
> It's not fully possible to turn mg into
It's a step in the right direction, but compare this:
# route add 5.5.5.1/26 127.0.0.1
add net 5.5.5.1/26: gateway 127.0.0.1
# route delete 5.5.5.1/26
delete net 5.5.5.1/26
...with this:
# route add -inet6 ff55::1/96 ::1
add net ff55::1/96: gateway ::1
# route delete -inet6 ff55::1/96
route: w
36 matches
Mail list logo
