Hello,
I have found a trivial bug in pf(4) DIOCKILLSTATES ioctl.
No functional change by this patch.
UMEZAWA Takeshi (FAMILY Given) umez...@iij.ad.jp
Internet Initiative Japan Inc.
diff --git a/sys/net/pf_ioctl.c
sysctl kern.random prints out a series of unintelligble numbers.
add some labels for more pretty.
also stop printing unused values. i don't need to verify that the pad
bytes are still zero. for that matter, we don't even need pad bytes.
Index: sys/dev/rndvar.h
As much as it pains me to submit a diff that contains + in the compat
directory, this is still mostly -. Calling our mixer devices NetBSD
devices doesn't make a whole lot of sense. Also kill some other dead
code.
The comment still doesn't make a lot of sense to me. The comment says
only 32
An analysis of the kernel using sophisticated machine learning pattern
matching algorithms reveals the presence of several function that are
never called and can be deleted.
Index: sys/exec_aout.h
===
RCS file:
After an absence of 9 years, I make my triumphant return to sys/nfs.
There are some silly programs out there (looking at you boost) that
actually use pathconf instead of just hard coding 1024 for max path
length. If you run them from nfs, fireworks ensue.
Here's a pathconf implementation for nfs,
There's a rather futile check for wrap around in crypto.c. The problem
is, if the number of crypto devs is anywhere near wrapping, the
malloc call a few lines below has long since exploded.
Just define a static max count and don't go over it.
Index: crypto.c
uvm_pagefree calls atomic_clearbits_int too many times. Just
accumulate the flags we need to zap, then do it once.
Index: uvm_page.c
===
RCS file: /cvs/src/sys/uvm/uvm_page.c,v
retrieving revision 1.122
diff -u -p -r1.122 uvm_page.c
the netmpls code includes various headers it doesn't really need.
Index: mpls.h
===
RCS file: /cvs/src/sys/netmpls/mpls.h,v
retrieving revision 1.25
diff -u -p -r1.25 mpls.h
--- mpls.h 8 Sep 2010 08:00:56 - 1.25
+++
it's 2013. we don't have to pay extra for vowels.
Index: nfs/nfs_vnops.c
===
RCS file: /cvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.140
diff -u -p -r1.140 nfs_vnops.c
--- nfs/nfs_vnops.c 17 Nov 2012 22:28:26 -
Date: Tue, 26 Mar 2013 05:03:59 -0400
From: Ted Unangst t...@tedunangst.com
it's 2013. we don't have to pay extra for vowels.
Even in 2013, my terminals are still 80 columns wide. This makes some
of the lines wrap. Not really an improvement if you ask me.
Index: nfs/nfs_vnops.c
These isa devs are already disabled and not particularly popular among
our users. affected: tcic, sea, wds, eg, el
Index: arch/i386/conf/GENERIC
===
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.744
diff -u
On Tue, Mar 26, 2013 at 10:09, Mark Kettenis wrote:
Date: Tue, 26 Mar 2013 05:03:59 -0400
From: Ted Unangst t...@tedunangst.com
it's 2013. we don't have to pay extra for vowels.
Even in 2013, my terminals are still 80 columns wide. This makes some
of the lines wrap. Not really an
OpenBSD 5.3-current (GENERIC) #11: Tue Mar 26 13:32:47 EST 2013
r...@nero.witworx.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) D CPU 3.20GHz (GenuineIntel 686-class) 3.21 GHz
cpu0:
I have sent the previous message to dmesg@ and to this list so that the
involved devs can see that not only the Intel 915 stuff works but so
does the D945.
Hope this is useful to jsg@ co.
Rod/
*** NOTE *** Please DO NOT CC me. I am subscribed to the list.
Mail to the sender address that does
Date: Tue, 26 Mar 2013 05:20:27 -0400
From: Ted Unangst t...@tedunangst.com
These isa devs are already disabled and not particularly popular among
our users. affected: tcic, sea, wds, eg, el
The reason these devices are disabled is probably that their probe
routines are destructive. So
On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
Date: Tue, 26 Mar 2013 05:20:27 -0400
From: Ted Unangst t...@tedunangst.com
These isa devs are already disabled and not particularly popular among
our users. affected: tcic, sea, wds, eg, el
The reason these devices are disabled is
Hello, Luis.
Now I am rewriting a driver for Microdia's USB TEMPer with
advices from yuo@ and deraadt@.
Please wait a while and thank you for trying my patch.
Thanks.
--
SASANO Takayoshi u...@mx5.nisiq.net
On Tue, Mar 26, 2013 at 5:09 PM, Ted Unangst t...@tedunangst.com wrote:
On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
Date: Tue, 26 Mar 2013 05:20:27 -0400
From: Ted Unangst t...@tedunangst.com
These isa devs are already disabled and not particularly popular among
our users. affected:
On Tue, Mar 26, 2013 at 09:09:14AM -0400, Ted Unangst wrote:
On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
Date: Tue, 26 Mar 2013 05:20:27 -0400
From: Ted Unangst t...@tedunangst.com
These isa devs are already disabled and not particularly popular among
our users. affected: tcic,
On Tue, Mar 26, 2013 at 1:51 AM, Ted Unangst t...@tedunangst.com wrote:
uvm_pagefree calls atomic_clearbits_int too many times.
Is there some sort of evidence that this is a problem - performace or
stability wise?
Just
accumulate the flags we need to zap, then do it once.
I get what you're
On Tue, Mar 26, 2013 at 14:26, Creamy wrote:
but I honestly question the utility of any of these ISA
network and SCSI drivers.
Perhaps somebody who is new to coding might be able to learn something
from them?
The last thing this world needs is more programmers who learned to
code by
Any objections for supporting write_opt=nodir for ustar archives?
Another option for Ruby gems will be going with GNU tar. :(
--
WBR,
Vadim Zhukov
Index: options.c
===
RCS file: /cvs/src/bin/pax/options.c,v
retrieving
Date: Tue, 26 Mar 2013 09:09:14 -0400
From: Ted Unangst t...@tedunangst.com
On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
Date: Tue, 26 Mar 2013 05:20:27 -0400
From: Ted Unangst t...@tedunangst.com
These isa devs are already disabled and not particularly popular among
our
Sorry, but I think there is some seriously strange reasoning going on here.
It's not so much that we spend time maintaining the source, but I do
spend time compiling it.
Err, don't you use a custom kernel configuration? Unless you're working
on those drivers, why are you compiling them in
Penned by Ted Unangst on 20130326 8:09.14, we have:
| On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
| Date: Tue, 26 Mar 2013 05:20:27 -0400
| From: Ted Unangst t...@tedunangst.com
|
| These isa devs are already disabled and not particularly popular among
| our users. affected: tcic
These isa devs are already disabled and not particularly popular among
our users. affected: tcic, sea, wds, eg, el
No objection against removing them from kernel configs (or commenting
them out), but keep files.isa unchanged please.
uvm_pagefree calls atomic_clearbits_int too many times.
Is there some sort of evidence that this is a problem - performace or
stability wise?
Platforms which can't do ll/sc style atomic operations usually wrap
these operations within splhigh()/splx() calls, which are a tad
expensive.
In
On Mar 26, 2013, at 6:26 PM, Creamy cre...@nocrater.com wrote:
but I honestly question the utility of any of these ISA
network and SCSI drivers.
Perhaps somebody who is new to coding might be able to learn something
from them?
There is such a vast amount of code in the different BSD
I really don't see the point of removing these from the tree. I just
don't see greater value from removal, vs retention.
Sure you can remove their compilation in GENERIC by #'ing them there.
That I can understand. But if you remove the lines, noone can ever
use them again because they won't
I don't think maintaining these drivers is currently a huge burden on
us. But decoupling them from the build will almost certainly lead to
some degree of bitrot.
This 2nd sentence is the truth. At least when something is coupled to
the build, it might warn us of the unintended consequences
uvm_pagefree calls atomic_clearbits_int too many times.
Is there some sort of evidence that this is a problem - performace or
stability wise?
Platforms which can't do ll/sc style atomic operations usually wrap
these operations within splhigh()/splx() calls, which are a tad
On Tue, Mar 26, 2013 at 10:55 AM, Miod Vallat m...@online.fr wrote:
uvm_pagefree calls atomic_clearbits_int too many times.
Is there some sort of evidence that this is a problem - performace or
stability wise?
Platforms which can't do ll/sc style atomic operations usually wrap
these
Todd T. Fries todd at fries.net writes:
I'd wager a bet that I could make my sea(4) scsi adapter work more
reliably than any variant of usb wi(4), so perhaps we should disable usb
wi(4) to save you time building instead?
My 2 cents.
Nuke tcic0 *and* pcic*:
* searching archives bring dmesgs
Well, you're right about one thing - the comment there says that it should
just return EINVAL for nfs v2 - and I think it should - but that code returns
EINVAL for v3 - and that's wrong. We have server side support for this in v3
and what we should probably be doing is actually doing the rpc call
and doing EINVAL in the v2 case.
Which won't solve the problem described in his mail.
Alexey E. Suslikov alexey.suslikov at gmail.com writes:
Not sure about ancient 3Com's, but they are Ethernet at
least, in contract to Token-Ring device like tr*.
Do we support Token-Ring?
Joystick driver?
On Tue, Mar 26, 2013 at 10:53 AM, Bob Beck b...@obtuse.com wrote:
Well, you're right about one thing - the comment there says that it should
just return EINVAL for nfs v2 - and I think it should - but that code returns
EINVAL for v3 - and that's wrong. We have server side support for this in
If I'm testing hardware support and such, I'm going to want to get
thorough coverage of the drivers we build and purport to support.
Next time mail in your dmesg! :)
I'd wager a bet that I could make my sea(4) scsi adapter work more
reliably than any variant of usb wi(4), so perhaps we
On Mar 26, 2013, at 10:06 PM, Creamy cre...@nocrater.com wrote:
Looking to the future, when are we going to drop 486 support, anyway?
Now, that's a more interesting thing ask.
How much of the hardware survives now, anyway? I mean at least the old
Vaxen were, (and are), maintainable. 486
On Tue, Mar 26, 2013 at 11:58 AM, Theo de Raadt dera...@cvs.openbsd.org wrote:
and doing EINVAL in the v2 case.
Which won't solve the problem described in his mail.
Of course it will - in the NFS v3 case, and in theory you'll be
getting what the server supports.
I don't think we should go
On Tue, Mar 26, 2013 at 12:51, Bob Beck wrote:
On Tue, Mar 26, 2013 at 11:58 AM, Theo de Raadt dera...@cvs.openbsd.org
wrote:
and doing EINVAL in the v2 case.
Which won't solve the problem described in his mail.
Of course it will - in the NFS v3 case, and in theory you'll be
getting what
On Mar 26, 2013, at 11:11 PM, Creamy cre...@nocrater.com wrote:
On Tue, Mar 26, 2013 at 10:50:40PM +0400, Franco Fichtner wrote:
Nobody in their right mind would have such a system as
mission critical infrastructure. :)
What, like using a Honeywell 316 as a nuclear power station
reactor
Let me explain my philosophy towards pathconf. It's like those
configure scripts that check to see if you have a working version of
strcpy. If you don't, you are so utterly boned you'll find out soon
enough. If the nfs server isn't going to let you create a 255
character name, you'll find out
Let me explain my philosophy towards pathconf. It's like those
configure scripts that check to see if you have a working version of
strcpy. If you don't, you are so utterly boned you'll find out soon
enough. If the nfs server isn't going to let you create a 255
character name, you'll
Good evening everyone,
I discovered about one or two weeks ago that I can't link any debug
libraries on OpenBSD. At first I thought it was a cmake update[1] but
then I started digging further and it turns out its our gcc.
What threw me off is that gcc-4.7 from ports behaves the same way, but
I
On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote:
Good evening everyone,
I discovered about one or two weeks ago that I can't link any debug
libraries on OpenBSD. At first I thought it was a cmake update[1] but
then I started digging further and it turns out its our gcc.
This is not
On Tue, Mar 26, 2013 at 09:15:38PM +0100, Pascal Stumpf wrote:
On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote:
Good evening everyone,
I discovered about one or two weeks ago that I can't link any debug
libraries on OpenBSD. At first I thought it was a cmake update[1] but
then I
Date: Tue, 26 Mar 2013 23:54:20 +0200
From: Paul Irofti p...@irofti.net
I don't understand how, can you go into more details please?
Anyway, can we then just ignore the -pg option if it doesn't work for
shared instead of breaking the link? Or do you have a better solution?
Perhaps ld
On Tue, 26 Mar 2013 23:54:20 +0200, Paul Irofti wrote:
On Tue, Mar 26, 2013 at 09:15:38PM +0100, Pascal Stumpf wrote:
On Tue, 26 Mar 2013 21:48:42 +0200, Paul Irofti wrote:
Good evening everyone,
I discovered about one or two weeks ago that I can't link any debug
libraries on
On Tue, 26 Mar 2013 23:05:05 +0100 (CET), Mark Kettenis wrote:
Date: Tue, 26 Mar 2013 23:54:20 +0200
From: Paul Irofti p...@irofti.net
I don't understand how, can you go into more details please?
Anyway, can we then just ignore the -pg option if it doesn't work for
shared instead of
On Tue, Mar 26, 2013 at 3:45 PM, Pascal Stumpf pascal.stu...@cubes.de wrote:
...
Anyway, can we then just ignore the -pg option if it doesn't work for
shared instead of breaking the link? Or do you have a better solution?
I could do that (if I figure out the correct gcc specs), sure.
Change
On Tue, 26 Mar 2013 16:39:54 -0700, Philip Guenther wrote:
On Tue, Mar 26, 2013 at 3:45 PM, Pascal Stumpf pascal.stu...@cubes.de wrote:
...
Anyway, can we then just ignore the -pg option if it doesn't work for
shared instead of breaking the link? Or do you have a better solution?
I could
It looks like copyright for sys/kern/sysv_ipc.c was assigned to NetBSD
in rev 1.13 in 1998:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/sysv_ipc.c.diff?r1=1.12r2=1.13only_with_tag=MAINf=h
NetBSD then dropped clauses 3 4 in rev 1.21 in 2008:
53 matches
Mail list logo
