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.12&r2=1.13&only_with_tag=MAIN&f=h
NetBSD then dropped clauses 3 & 4 in rev 1.21 in 2008:
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/k
On Tue, 26 Mar 2013 16:39:54 -0700, Philip Guenther wrote:
> On Tue, Mar 26, 2013 at 3:45 PM, Pascal Stumpf 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 (i
On Tue, Mar 26, 2013 at 3:45 PM, Pascal Stumpf 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 this:
%l %{pie:
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
> > 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 break
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
> > > libr
> Date: Tue, 26 Mar 2013 23:54:20 +0200
> From: Paul Irofti
> 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 shouldn't set l
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
>
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 no
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 la
> > 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, y
> 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
On Mar 26, 2013, at 11:11 PM, Creamy 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 temperature mon
On Tue, Mar 26, 2013 at 12:51, Bob Beck wrote:
> On Tue, Mar 26, 2013 at 11:58 AM, Theo de Raadt
> 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 s
On Tue, Mar 26, 2013 at 11:58 AM, Theo de Raadt 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 outside the nfs v2 spec
On Mar 26, 2013, at 10:06 PM, Creamy 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 motherboa
> 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 s
On Tue, Mar 26, 2013 at 10:53 AM, Bob Beck 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 v3
> and what
Alexey E. Suslikov 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?
> and doing EINVAL in the v2 case.
Which won't solve the problem described in his mail.
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
Todd T. Fries 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 from
On Tue, Mar 26, 2013 at 10:55 AM, Miod Vallat 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 operation
> > > 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
> 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
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 kno
On Mar 26, 2013, at 6:26 PM, 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?
There is such a vast amount of code in the different BSD flavours
alone that
> > 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.
I
> 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.
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
| >>
| >> These isa devs are already disabled and not particularly popular among
| >> our us
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 an
> Date: Tue, 26 Mar 2013 09:09:14 -0400
> From: Ted Unangst
>
> On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
> >> Date: Tue, 26 Mar 2013 05:20:27 -0400
> >> From: Ted Unangst
> >>
> >> These isa devs are already disabled and not particularly popular among
> >> our users. affected: tcic,
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 revision
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
On Tue, Mar 26, 2013 at 1:51 AM, Ted Unangst 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 trying to do, but
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
> >>
> >> These isa devs are already disabled and not particularly popular among
> >> our users. affected: tcic, sea
On Tue, Mar 26, 2013 at 5:09 PM, 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
>>>
>>> These isa devs are already disabled and not particularly popular among
>>> our users. affected: tcic, sea, wds, eg, el
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
On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
>> Date: Tue, 26 Mar 2013 05:20:27 -0400
>> From: Ted Unangst
>>
>> 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
> Date: Tue, 26 Mar 2013 05:20:27 -0400
> From: Ted Unangst
>
> 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 the fact that the
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 subscribed to the list.
Mail to the sender address that does not
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:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,
On Tue, Mar 26, 2013 at 10:09, Mark Kettenis wrote:
>> Date: Tue, 26 Mar 2013 05:03:59 -0400
>> From: Ted Unangst
>>
>> 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 y
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 -p
> Date: Tue, 26 Mar 2013 05:03:59 -0400
> From: Ted Unangst
>
> 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
> ==
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 - 1.1
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
+++ mpl
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
-
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
==
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,
49 matches
Mail list logo
