> > I did not want to list all isa drivers which happen to be tested a few
> > times every year either.
>
> OK, put it this way, there are at least some of the ISA drivers which
> people are not using on a regular basis, and they are broken as a result
> of that. Agree or not? We've *seen* examp
libkvm already figures out the pagesize of the machine in _kvm_open(),
and then allows the machine-dependent _kvm_initvtop() to override it
if need be (thereby, handling sparc). Thus we can avoid the PAGE_SIZE,
PAGE_SHIFT, ... variables.
Seems to be working ... wonder if I missed some relevant te
What does bpf have to do with the namecache? I was wondering the same
thing every time I saw bpf.o get recompiled after editing namei.h. Oh,
vnode.h includes namei.h. Just because.
Shuffle that line out to the exactly one place that needs it.
Index: kern/vfs_init.c
===
Hi,
I'm re-posting this in hope. :)
http://marc.info/?l=openbsd-tech&m=135698142814632&w=2
Please let me know if I can provide any further info.
- Michael
my thoughts inline...
On 03/26/13 05:20, Ted Unangst wrote:
> 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: /
And yet again for expr :-).
$ expr -2147483648 / -1
Floating point exception (core dumped)
expr on Linux (GNU or whatever it is) reports "Numerical result out of
range" for this. But it does the same for other overflows (such as "expr
-9223372036854775808 - 1" on a 64-bit platform) where we just
I'd like to move the memory poisoning out of kern_malloc so I can use
it in subr_pool as well. This opens the door for poisoning strategies
more complicated than "splat 0xdeadbeef".
Index: kern/kern_malloc.c
===
RCS file: /cvs/src/sys
On Wed, Mar 27, 2013 at 04:27:22PM -0700, Matthew Dempsky wrote:
> On Wed, Mar 27, 2013 at 4:15 PM, Nicholas Marriott
> wrote:
> > Sure, that actually looks to be what other shells do anyhow.
>
> That looks ok to me.
>
> Which shells did you check, out of curiosity? On Goobuntu, both bash
> and
On Wed, Mar 27, 2013 at 4:15 PM, Nicholas Marriott
wrote:
> Sure, that actually looks to be what other shells do anyhow.
That looks ok to me.
Which shells did you check, out of curiosity? On Goobuntu, both bash
and dash give SIGFPE too actually.
Checking POSIX, I notice that it requires that s
And the same for csh (@ x = -2147483648 % -1):
Index: exp.c
===
RCS file: /cvs/src/bin/csh/exp.c,v
retrieving revision 1.9
diff -u -p -r1.9 exp.c
--- exp.c 20 Jul 2010 02:13:10 - 1.9
+++ exp.c 27 Mar 2013 23:23:48
On 03/27/2013 03:06 PM, Chris Cappuccio wrote:
OpenBSD/i386 isn't likely to change major platform support any time
soon, if ever. The port for dropping legacy crap would be
OpenBSD/amd64. Now, look at its kernel config. You'll see, that was
already done. ta-da! I bought an old, high-end 80386 s
Sure, that actually looks to be what other shells do anyhow.
Index: expr.c
===
RCS file: /cvs/src/bin/ksh/expr.c,v
retrieving revision 1.21
diff -u -p -r1.21 expr.c
--- expr.c 1 Jun 2009 19:00:57 - 1.21
+++ expr.c
On Wed, Mar 27, 2013 at 3:56 PM, Nicholas Marriott
wrote:
> case O_DIV:
> case O_DIVASN:
> + if (vl->val.i == LONG_MIN && vr->val.i == -1)
> + evalerr(es, ET_STR, "can't represent result");
>
Hi
On i386:
$ ksh -c 'echo $((-2147483648 / -1))'
Floating point exception (core dumped)
$ ksh -c 'echo $((-2147483648 % -1))'
Floating point exception (core dumped)
Was the same at least on amd64 with LONG_MIN last I could check.
Perhaps something like this?
Index: expr.c
===
Alexey Suslikov wrote:
> Can OpenBSD use SSE4.2 CRC32 (found on Core i7) to speedup
> TCP/IP checksum calculations?
TCP, UDP, and IPv4 checksums are simple sums and don't involve CRCs.
Also, the SSE4.2 CRC32 instruction uses the Castagnoli polynomial,
which is different from the more commonly u
On Wed, 27 Mar 2013 19:24:49 +
Kevin Chadwick wrote:
> However, I would be glad if the 486 support was kept as I have many
> 486 systems that I would like to be able to use if I ever get around
> to porting the ethernet driver (which is open source).
Oops, just checked and they are 586 and t
> Really, this community has an attitude problem - and you *need*
> more developers, believe me, you shouldn't be trying to scare
> them away.
You're right. We need more developers.
What we don't need is more people who have the time to send 25
long opinionated rants to our mailing lists.
So pu
> Don't forget, though, this *is* open source. If the project officially
> drops support for anything you like, ultimately you are free to fork it.
It is. And we are the developers, and you are not. So put a sock in it.
Creamy [cre...@nocrater.com] wrote:
>
> So, you see, killing 486 support might be no advantage in itself, but it opens
> up possibilities further down the line, that won't exist all the time we're
> dragging all this old stuff along with us.
>
OpenBSD/i386 isn't likely to change major platform s
Creamy [cre...@nocrater.com] wrote:
>
> Miod, you seem like an all-right bloke, and I don't want to create
> bad feelings, but you're insulting me on a public mailing list,
> because I dare to bring up something you object to.
>
> Other people have been rude to me in private mail, because my view
On Wed, Mar 27, 2013 at 10:24 PM, Miod Vallat wrote:
>> >> Do we support Token-Ring?
>> >
>> > We used to, on TRopic boards, but since public documentation for TR
>> > hardware amounts to zilch, and there is no interest in changing this
>> > situation, it was eventually removed from the tree to cl
> What you're suggesting is a small part of the ISA code in the tree.
I did not want to list all isa drivers which happen to be tested a few
times every year either.
> ...and note that I've been working on the pckbc code for the last
> couple of weeks, so I should be fully aware of it's existance
On Wed, Mar 27, 2013 at 08:14:20PM +, Creamy wrote:
> On Wed, Mar 27, 2013 at 08:05:47PM +, Miod Vallat wrote:
> > > In fact, to everybody else who is reading this, doesn't it just point out
> > > that 486 support is, effectively, already broken, (as I suspected),
> > > because the devices
On 03/27/2013 01:01 PM, Creamy wrote:
Or, more realistically, perhaps you could just choose to maintain the
-patch branch of a particular version that was of interest to you. For
example, if we stopped supporting 486 in 6.0, by way of example, what
is to stop you taking 6.0 and maintaining a -p
> Soekris NET4501 are still in use, and they are based upon 80486 cores.
> `Key' ISA devices such as wdc are still heavily tested as pcmcia or such
> attachments on i386 and non-i386 platforms. Other devices such as
> com(4), pckbc(4), still exist on many systems, even if they are no
> longer on ex
On Wed, Mar 27, 2013 at 08:05:47PM +, Miod Vallat wrote:
> > In fact, to everybody else who is reading this, doesn't it just point out
> > that 486 support is, effectively, already broken, (as I suspected),
> > because the devices that typically go with machines of that era are
> > suffering bi
> On Wed, Mar 27, 2013 at 08:05:47PM +, Miod Vallat wrote:
> > > In fact, to everybody else who is reading this, doesn't it just point out
> > > that 486 support is, effectively, already broken, (as I suspected),
> > > because the devices that typically go with machines of that era are
> > > su
> >> Do we support Token-Ring?
> >
> > We used to, on TRopic boards, but since public documentation for TR
> > hardware amounts to zilch, and there is no interest in changing this
> > situation, it was eventually removed from the tree to clear the way of
> > other changes.
>
> And with no TR stack
On Wed, Mar 27, 2013 at 10:04 PM, Miod Vallat wrote:
>> 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?
>
> We used to, on TRopic boards, but since public documentation for TR
> hardware amounts to zilch,
> In fact, to everybody else who is reading this, doesn't it just point out
> that 486 support is, effectively, already broken, (as I suspected),
> because the devices that typically go with machines of that era are
> suffering bit-rot in the tree?
Absolutely not. First, 80486 support is not broke
On Tue, 26 Mar 2013 07:28:20 +0100, Ted Unangst wrote:
> 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 below diff reflect
> 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?
We used to, on TRopic boards, but since public documentation for TR
hardware amounts to zilch, and there is no interest in changing this
situation, it was ev
On Wed, Mar 27, 2013 at 12:08:51PM -0700, Chuck Guzis wrote:
> On 03/27/2013 09:35 AM, Alexey G. Khramkov wrote:
> >Please, don't do this.
>
> >I've jumped from OpenBSD to NetBSD boat when SCSI driver were
> >rewritten to the "new" version (between 3.1-stable and 3.2-stable),
> >and my "very br
On Tue, 26 Mar 2013, Bob Beck wrote:
> So, does that make the case for fixing this in VOP_PATHCONF instead?
>
> Call the underlying filesystem call if it's there? and if not return the
> "something sane" there? then we have our "something defaultly sane"
> shit in one place?
>
> Just thinking
> However, on a practical level, if we took the decision to kill 486 support,
> we could, in effect, loose 99% of the ISA-related code, as excluding a few
> specialised pieces of hardware, (which OpenBSD doesn't support, and probably
> never will), ISA pretty much died by the 586 era, (as did VL-bu
On 03/27/2013 09:35 AM, Alexey G. Khramkov wrote:
Please, don't do this.
I've jumped from OpenBSD to NetBSD boat when SCSI driver were
rewritten to the "new" version (between 3.1-stable and 3.2-stable),
and my "very branded" HP NetServer with AIC-7770 (which can work on
IRQ 14 when primary I
Hi,
> Please, don't do this.
What exactly? You quoted my entire mail, but didn't narrow down exactly
which of my suggestions would cause problems for you.
> I've jumped from OpenBSD to NetBSD boat when SCSI driver were rewritten
> to the "new" version (between 3.1-stable and 3.2-stable), and my
Hi tech@.
Can OpenBSD use SSE4.2 CRC32 (found on Core i7) to speedup
TCP/IP checksum calculations?
Cheers,
Alexey
Hi,
The call to in_pcballoc() in user request attach is handled in three
different ways. Use the same code in udp_usrreq() and rip_usrreq()
and rip6_usrreq(). Also put an splsoftassert() into in_pcballoc()
for safety.
If I understand the code correctly, this also fixes a pcb and socket
leak in
Hello all.
On Wed, 27 Mar 2013 13:01:34 +
Creamy wrote:
> On Wed, Mar 27, 2013 at 10:43:53AM +, Stuart Henderson wrote:
> > On 2013/03/26 18:06, Creamy wrote:
> > > On Tue, Mar 26, 2013 at 09:00:39PM +0400, Franco Fichtner wrote:
> > > > On Mar 26, 2013, at 6:26 PM, Creamy wrote:
> > >
Hi,
I have ported NetBSD's tmpfs to OpenBSD. The port should be functional
on i386 and amd64. I haven't tested on other architectures. There are
limitations: update of mount options is not supported and the number of
nodes in a tmpfs file system is limited by the number of anonymous UVM
objects w
On Wed, Mar 27, 2013 at 10:43:53AM +, Stuart Henderson wrote:
> On 2013/03/26 18:06, Creamy wrote:
> > On Tue, Mar 26, 2013 at 09:00:39PM +0400, Franco Fichtner wrote:
> > > On Mar 26, 2013, at 6:26 PM, Creamy wrote:
> > > > Looking to the future, when are we going to drop 486 support, anyway?
2013/3/27 Stuart Henderson
> This patch only helped some quite uncommon cards with rf 6.0,
> the normal ones have rf 10.2 which these diffs didn't help, and made
> worse in some cases (system hangs).
>
Oh... So can I have a little request for someone skilled in patching driver
to help with this
On 2013/03/27 12:27, Hubert Jarosz wrote:
> Hi,
> I'm trying to install OpenBSD on my laptop with AR5424 but it fails. The
> question is: wasn't the patch which I found (
> http://marc.info/?t=12643791922) merged into OpenBSD official
> repository or it's bugged?
> Have maybe anyone tried testi
On 03/27/13 12:27, Hubert Jarosz wrote:
> Hi,
> I'm trying to install OpenBSD on my laptop with AR5424 but it fails. The
> question is: wasn't the patch which I found (
> http://marc.info/?t=12643791922) merged into OpenBSD official
> repository or it's bugged?
>
If I remember well it breaks a
Hi,
I'm trying to install OpenBSD on my laptop with AR5424 but it fails. The
question is: wasn't the patch which I found (
http://marc.info/?t=12643791922) merged into OpenBSD official
repository or it's bugged?
Have maybe anyone tried testing/developing those patches since 2010?
Retards,
Hube
On 2013/03/26 18:06, Creamy wrote:
> On Tue, Mar 26, 2013 at 09:00:39PM +0400, Franco Fichtner wrote:
> > On Mar 26, 2013, at 6:26 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 h
On Tue, Mar 26, 2013 at 09:00:39PM +0400, Franco Fichtner wrote:
> 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
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 monitor in to the early 2000s, until it's
hard disk failed
49 matches
Mail list logo
