Re: goodbye to some isa devices
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? Don't worry, it's been replaced with a couple of PDP11/70's, so we can all sleep well at night. N.B. This one *isn't* a joke. -- Creamy
Re: goodbye to some isa devices
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? > > There is such a vast amount of code in the different BSD flavours > alone that it becomes very unlikely someone will stumble upon ISA > code bits, especially if one is a novice programmer. And how many > of those are old enough to have seen what ISA looks like nowadays? I can see your reasoning, but I was thinking more along the lines of old school coders who are perhaps alien to unix systems programming, and/or C in general. Maybe there aren't as many of them around as I imagined. > Looking at diffs which remove ISA relevant stuff is probably the only > time they will see it -- that's educational *and* teducational at the > same time. Sorry for the bad pun. On reflection, it's not a good reason in itself to keep them in the tree. > > 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 motherboard dies, what do you do? Chances are it's a multi-layer pcb, so if traces go bad within it, a repair is going to be almost impossible. On Tue, Mar 26, 2013 at 12:18:03PM -0400, Ted Unangst wrote: > 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 reading old unmaintained ISA drivers. Try to see both sides of it though, for somebody like myself who has a background in embedded systems, and learned to code by writing z80 assembler. When I first came to unix systems programming and C in general, I could follow the logical flow of what I was reading, even though I couldn't write a line of compatible code myself, (some would say I still can't ;-) ). I learned a lot by looking at things like drivers for Hercules mono cards, which basically consisted of mode setting and a dumb framebuffer. I doubt whether today's generation in a similar situation would learn much from looking at any of the code for the latest ATI or Nvidia cards. -- Creamy
Re: goodbye to some isa devices
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 hardware survives now, anyway? I mean at least the old > Vaxen were, (and are), maintainable. 486 motherboard dies, what do you > do? Chances are it's a multi-layer pcb, so if traces go bad within it, > a repair is going to be almost impossible. Some of the 486-class embedded boards are quite solid hardware and not likely to die anytime soon. What advantage would there be to dropping 486 support anyway?
Re: Add support to AR5424
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, Hubert
Re: Add support to AR5424
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 at least hidden SSID and maybe also some working devices. Cheers Giovanni
Re: Add support to AR5424
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 testing/developing those patches since 2010? > > Retards, > Hubert 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). I don't believe the later versions of patches were ever tested with AR5212, certainly the earlier ones broke this chip when connecting a network with hidden SSID.
Re: Add support to AR5424
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 network card? I'm not as skilled, so I can only help with testing... (And I would be really happy using OpenBSD also on my laptop. Probably many other people too.) Thank you in advance for your help!
Re: goodbye to some isa devices
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? > > > > > > 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 motherboard dies, what do you > > do? Chances are it's a multi-layer pcb, so if traces go bad within it, > > a repair is going to be almost impossible. > > Some of the 486-class embedded boards are quite solid hardware and > not likely to die anytime soon. Agreed, but my experience was that those of us who were in the habbit of purchasing kit with decent build quality, in preference to the latest 'features', back in the day, were also the ones who tended to sell and replace it. The old boards that people are trying to keep in operation now, ironically, tend to be the rubbish ones. At least that's my experience, but others' may differ. > What advantage would there be to dropping 486 support anyway? In itself, perhaps not much, I very much doubt whether we'd see any use from being able to build the default distribution with 586+ compiler options, for example. 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-bus). As I pointed out in a previous post, we still have a Y2K workaround in the clock code, which is pointless on AMD64, anyway, and just a hang-over from taking the code straight from the i386 port. How many 586+ machines needed this workaround, anyway? Maybe some of the original P60 systems did, I honestly don't remember, but the number would be very small, if it is >0. I'm not claiming that dropping 486 support is the right thing to do right now, but I think it should be in our minds as an option. Look to the future, at what point did booting from CD-ROM become standard in BIOSes? I only used a few select brands of kit back then, generally the higher quality ones, so maybe I am off the mark here, but I never remember seeing a second-generation Pentium, (I.E. P75+), that lacked this feature. So, maybe we could eventually loose the need for boot floppy support, and we could overhaul the instructions in the official disc set, and make better use of those pages explaining the floppy install, which nobody uses, for something more useful. We could probably also loose the force-CHS code in the bootloader, which would save some very precious space, and allow us to use it for something more useful. For example, I'm obviously not using that on AMD64, so I added the feature to force booting of partition 3, regardless of which is flagged as active. Why? I was messing around with some assembler stuff on the raw hardware, (effectively writing my own OS, if you want to call it that, but all it did was print some text using the BIOS, it's a long story why I'm doing this, I'll tell the interested parties, (I.E. nobody), some other time), and I had flagged partition 0 as active, and had to boot from the 5.2 CD to set it back, as my 'os' has no fdisk program, (or any programs for the foreseeable future). However, it struck me that somebody dual-booting with Windows would probably have the same problem, because as far as I know you can't set an arbitrary partition active with fdisk in Windows, but I really don't know or care, because I don't use it. 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. -- Creamy
tmpfs
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 we can allocate. Otherwise, give it a go. The diff can be found at: http://block.io/tmp/tmpfs.diff You will need a new kernel with option TMPFS enabled, fresh include files and mount_tmpfs. tmpfs is a better MFS, it is faster and can free unused memory. -p.
Re: goodbye to some isa devices
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: > > > > > 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 motherboard dies, what do you > > > do? Chances are it's a multi-layer pcb, so if traces go bad within it, > > > a repair is going to be almost impossible. > > > > Some of the 486-class embedded boards are quite solid hardware and > > not likely to die anytime soon. > > Agreed, but my experience was that those of us who were in the habbit of > purchasing kit with decent build quality, in preference to the latest > 'features', back in the day, were also the ones who tended to sell and replace > it. > > The old boards that people are trying to keep in operation now, ironically, > tend to be the rubbish ones. At least that's my experience, but others' > may differ. > > > What advantage would there be to dropping 486 support anyway? > > In itself, perhaps not much, I very much doubt whether we'd see any use from > being able to build the default distribution with 586+ compiler options, for > example. > > 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-bus). > > As I pointed out in a previous post, we still have a Y2K workaround in the > clock code, which is pointless on AMD64, anyway, and just a hang-over from > taking the code straight from the i386 port. How many 586+ machines needed > this workaround, anyway? Maybe some of the original P60 systems did, I > honestly don't remember, but the number would be very small, if it is >0. > > I'm not claiming that dropping 486 support is the right thing to do right > now, but I think it should be in our minds as an option. Look to the future, > at what point did booting from CD-ROM become standard in BIOSes? I only used > a few select brands of kit back then, generally the higher quality ones, so > maybe I am off the mark here, but I never remember seeing a second-generation > Pentium, (I.E. P75+), that lacked this feature. > > So, maybe we could eventually loose the need for boot floppy support, and > we could overhaul the instructions in the official disc set, and make better > use of those pages explaining the floppy install, which nobody uses, for > something more useful. > > We could probably also loose the force-CHS code in the bootloader, which would > save some very precious space, and allow us to use it for something more > useful. > > For example, I'm obviously not using that on AMD64, so I added the feature to > force booting of partition 3, regardless of which is flagged as active. Why? > I was messing around with some assembler stuff on the raw hardware, > (effectively > writing my own OS, if you want to call it that, but all it did was print some > text using the BIOS, it's a long story why I'm doing this, I'll tell the > interested parties, (I.E. nobody), some other time), and I had flagged > partition > 0 as active, and had to boot from the 5.2 CD to set it back, as my 'os' has > no fdisk program, (or any programs for the foreseeable future). > > However, it struck me that somebody dual-booting with Windows would probably > have > the same problem, because as far as I know you can't set an arbitrary > partition > active with fdisk in Windows, but I really don't know or care, because I don't > use it. > > 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. > > -- > Creamy 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 IDE channel is disabled or IRQ 15 when IDE channel is enabled, no other IRQs are possible) ceased to work. For now, my old Acer netbook with AMD Turion processor is "too old" for NetBSD (my touchpad doesn't work "out of the box"). That's why I'm reading this mail list. Just FYI. HTH, -- ynzo
pcballoc in usrreq
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 udp_usrreq() in case soreserve() fails.
ok?
bluhm
Index: netinet/in_pcb.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.131
diff -u -p -r1.131 in_pcb.c
--- netinet/in_pcb.c5 Feb 2013 19:09:52 - 1.131
+++ netinet/in_pcb.c27 Mar 2013 16:35:19 -
@@ -177,6 +177,8 @@ in_pcballoc(struct socket *so, struct in
struct inpcb *inp;
int s;
+ splsoftassert(IPL_SOFTNET);
+
if (inpcb_pool_initialized == 0) {
pool_init(&inpcb_pool, sizeof(struct inpcb), 0, 0, 0,
"inpcbpl", NULL);
Index: netinet/raw_ip.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.62
diff -u -p -r1.62 raw_ip.c
--- netinet/raw_ip.c21 Oct 2012 13:06:03 - 1.62
+++ netinet/raw_ip.c27 Mar 2013 17:37:29 -
@@ -396,8 +396,9 @@ int
rip_usrreq(struct socket *so, int req, struct mbuf *m, struct mbuf *nam,
struct mbuf *control, struct proc *p)
{
- int error = 0;
struct inpcb *inp = sotoinpcb(so);
+ int error = 0;
+ int s;
#ifdef MROUTING
extern struct socket *ip_mrouter;
#endif
@@ -419,9 +420,13 @@ rip_usrreq(struct socket *so, int req, s
error = EACCES;
break;
}
+ s = splsoftnet();
if ((error = soreserve(so, rip_sendspace, rip_recvspace)) ||
- (error = in_pcballoc(so, &rawcbtable)))
+ (error = in_pcballoc(so, &rawcbtable))) {
+ splx(s);
break;
+ }
+ splx(s);
inp = (struct inpcb *)so->so_pcb;
inp->inp_ip.ip_p = (long)nam;
break;
Index: netinet/udp_usrreq.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.154
diff -u -p -r1.154 udp_usrreq.c
--- netinet/udp_usrreq.c14 Mar 2013 11:18:37 - 1.154
+++ netinet/udp_usrreq.c27 Mar 2013 18:17:47 -
@@ -1151,13 +1151,12 @@ udp_usrreq(struct socket *so, int req, s
break;
}
s = splsoftnet();
- error = in_pcballoc(so, &udbtable);
- splx(s);
- if (error)
- break;
- error = soreserve(so, udp_sendspace, udp_recvspace);
- if (error)
+ if ((error = soreserve(so, udp_sendspace, udp_recvspace)) ||
+ (error = in_pcballoc(so, &udbtable))) {
+ splx(s);
break;
+ }
+ splx(s);
#ifdef INET6
if (((struct inpcb *)so->so_pcb)->inp_flags & INP_IPV6)
((struct inpcb *) so->so_pcb)->inp_ipv6.ip6_hlim =
Index: netinet6/raw_ip6.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/raw_ip6.c,v
retrieving revision 1.47
diff -u -p -r1.47 raw_ip6.c
--- netinet6/raw_ip6.c 14 Mar 2013 11:18:37 - 1.47
+++ netinet6/raw_ip6.c 27 Mar 2013 17:37:43 -
@@ -595,8 +595,8 @@ rip6_usrreq(struct socket *so, int req,
struct mbuf *control, struct proc *p)
{
struct in6pcb *in6p = sotoin6pcb(so);
- int s;
int error = 0;
+ int s;
int priv;
priv = 0;
@@ -616,12 +616,8 @@ rip6_usrreq(struct socket *so, int req,
break;
}
s = splsoftnet();
- if ((error = soreserve(so, rip6_sendspace, rip6_recvspace)) !=
0) {
- splx(s);
- break;
- }
- if ((error = in_pcballoc(so, &rawin6pcbtable)) != 0)
- {
+ if ((error = soreserve(so, rip6_sendspace, rip6_recvspace)) ||
+ (error = in_pcballoc(so, &rawin6pcbtable))) {
splx(s);
break;
}
SSE4.2 CRC32 question
Hi tech@. Can OpenBSD use SSE4.2 CRC32 (found on Core i7) to speedup TCP/IP checksum calculations? Cheers, Alexey
Re: goodbye to some isa devices
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 "very > branded" HP NetServer with AIC-7770 (which can work on IRQ 14 when > primary IDE channel is disabled or IRQ 15 when IDE channel is enabled, > no other IRQs are possible) ceased to work. For now, my old Acer netbook > with AMD Turion processor is "too old" for NetBSD (my touchpad doesn't > work "out of the box"). That's why I'm reading this mail list. I searched the archives for -tech and -misc, but couldn't find any posts from you about this. Both sound like problems that would be fairly easily addressed. Have you tried to boot any OpenBSD version since 3.2 on the HP? > Just FYI. Well, that's the whole point of this list :-). I really wasn't suggesting dropping 486, ISA, or boot floppy support any time soon. I assume that the HP is a 486, by the way? The NetServer line covers a lot of machines. 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? -- Creamy
Re: goodbye to some isa devices
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 IDE channel is disabled or IRQ 15 when IDE channel is enabled, no other IRQs are possible) ceased to work. For now, my old Acer netbook with AMD Turion processor is "too old" for NetBSD (my touchpad doesn't work "out of the box"). That's why I'm reading this mail list. Just FYI. I've got to join my voice with Alexey here. A good part of my work is resurrecting and keeping old specialized industrial equipment going. This is the world where 8" floppies are not uncommon and I get requests to retrieve data from old DC300XL QIC carts. Since the controller (and any interface cards) are part of what makes the equipment go, it just isn't a matter of getting a new commodity box and installing new software. If you have a quarter-million invested in a specialized tool, it pays to keep it going as long as possible. My point (and I think, Alexey's) is that not everyone uses BSD for browsing the web and exchanging email. There are still some applications out there that are still running on the same equipment from 20 years ago. I find that NetBSD's "Of course it runs NetBSD" slogan rings a little hollow these days. Perhaps expecting software to run on both new and old gear isn't practical. If that's the case, I'll continue to hang onto my old copies of distros, the same way that I hang onto copies of MS-DOS, Windows 3.1 and Windows 98. All the best, Chuck Guzis Eugene, OR
Re: goodbye to some isa devices
> 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-bus). Whilst I have some p500 systems that I am not using with both pci and ISA. I certainly have no care for ISA. 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). -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: nfs pathconf
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 outloud...
Could you stop that? I can hear you from here and It's hard to think over
the bellowing!
Diff below pulls into VOP_PATHCONF() the tests for _PC_PATH_MAX,
_PC_PIPE_BUF, _PC_ASYNC_IO, _PC_PRIO_IO, and _PC_SYNC_IO. Since the
latter three aren't supported anywhere, we can define the related
_POSIX_{ASYNC,PRIO,SYNC}_IO symbols in with value -1.
Also: zap pointless tty-only values from procfs(!).
(I have another diff for _PC_TIMESTAMP_RESOLUTION support, but that's
conceptually separate.)
Index: sys/isofs/cd9660/cd9660_vnops.c
===
RCS file: /cvs/src/sys/isofs/cd9660/cd9660_vnops.c,v
retrieving revision 1.57
diff -u -p -r1.57 cd9660_vnops.c
--- sys/isofs/cd9660/cd9660_vnops.c 26 Sep 2012 04:32:40 - 1.57
+++ sys/isofs/cd9660/cd9660_vnops.c 27 Mar 2013 19:54:57 -
@@ -876,12 +876,6 @@ cd9660_pathconf(void *v)
else
*ap->a_retval = 37;
break;
- case _PC_PATH_MAX:
- *ap->a_retval = PATH_MAX;
- break;
- case _PC_PIPE_BUF:
- *ap->a_retval = PIPE_BUF;
- break;
case _PC_CHOWN_RESTRICTED:
*ap->a_retval = 1;
break;
Index: sys/isofs/udf/udf_vnops.c
===
RCS file: /cvs/src/sys/isofs/udf/udf_vnops.c,v
retrieving revision 1.45
diff -u -p -r1.45 udf_vnops.c
--- sys/isofs/udf/udf_vnops.c 20 Jun 2012 17:30:22 - 1.45
+++ sys/isofs/udf/udf_vnops.c 27 Mar 2013 19:54:57 -
@@ -401,9 +401,6 @@ udf_pathconf(struct vop_pathconf_args *a
case _PC_NAME_MAX:
*ap->a_retval = NAME_MAX;
break;
- case _PC_PATH_MAX:
- *ap->a_retval = PATH_MAX;
- break;
case _PC_NO_TRUNC:
*ap->a_retval = 1;
break;
Index: sys/kern/spec_vnops.c
===
RCS file: /cvs/src/sys/kern/spec_vnops.c,v
retrieving revision 1.69
diff -u -p -r1.69 spec_vnops.c
--- sys/kern/spec_vnops.c 20 Jun 2012 17:30:22 - 1.69
+++ sys/kern/spec_vnops.c 27 Mar 2013 19:54:57 -
@@ -617,9 +617,6 @@ spec_pathconf(void *v)
case _PC_MAX_INPUT:
*ap->a_retval = MAX_INPUT;
break;
- case _PC_PIPE_BUF:
- *ap->a_retval = PIPE_BUF;
- break;
case _PC_CHOWN_RESTRICTED:
*ap->a_retval = 1;
break;
Index: sys/kern/vfs_vops.c
===
RCS file: /cvs/src/sys/kern/vfs_vops.c,v
retrieving revision 1.4
diff -u -p -r1.4 vfs_vops.c
--- sys/kern/vfs_vops.c 2 Jul 2011 15:52:25 - 1.4
+++ sys/kern/vfs_vops.c 27 Mar 2013 19:54:57 -
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#ifdef VFSLCKDEBUG
#define ASSERT_VP_ISLOCKED(vp) do { \
@@ -562,6 +563,25 @@ int
VOP_PATHCONF(struct vnode *vp, int name, register_t *retval)
{
struct vop_pathconf_args a;
+
+ /*
+* Handle names that are constant across filesystem
+*/
+ switch (name) {
+ case _PC_PATH_MAX:
+ *retval = PATH_MAX;
+ return (0);
+ case _PC_PIPE_BUF:
+ *retval = PIPE_BUF;
+ return (0);
+ case _PC_ASYNC_IO:
+ case _PC_PRIO_IO:
+ case _PC_SYNC_IO:
+ *retval = 0;
+ return (0);
+
+ }
+
a.a_vp = vp;
a.a_name = name;
a.a_retval = retval;
Index: sys/miscfs/fifofs/fifo_vnops.c
===
RCS file: /cvs/src/sys/miscfs/fifofs/fifo_vnops.c,v
retrieving revision 1.37
diff -u -p -r1.37 fifo_vnops.c
--- sys/miscfs/fifofs/fifo_vnops.c 20 Jun 2012 17:30:22 - 1.37
+++ sys/miscfs/fifofs/fifo_vnops.c 27 Mar 2013 19:54:57 -
@@ -414,9 +414,6 @@ fifo_pathconf(void *v)
case _PC_LINK_MAX:
*ap->a_retval = LINK_MAX;
break;
- case _PC_PIPE_BUF:
- *ap->a_retval = PIPE_BUF;
- break;
case _PC_CHOWN_RESTRICTED:
*ap->a_retval = 1;
break;
Index: sys/miscfs/procfs/procfs_vnops.c
===
RCS file: /cvs/src/sys/miscfs/procfs/procfs_vnops.c,v
retrieving revision 1.55
diff -u -p -r1.55 procfs_vnops.c
--- sys/miscfs/procfs/procfs_vnops.c20 Jun 2012 17:30:22 - 1.55
+++ sys/miscfs/procfs/procfs_vnops.c
Re: goodbye to some isa devices
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 branded" HP NetServer with AIC-7770 (which can work on > >IRQ 14 when primary IDE channel is disabled or IRQ 15 when IDE channel > >is enabled, no other IRQs are possible) ceased to work. For now, my > >old Acer netbook with AMD Turion processor is "too old" for NetBSD (my > >touchpad doesn't work "out of the box"). That's why I'm reading this > >mail list. Just FYI. > > I've got to join my voice with Alexey here. A good part of my work is > resurrecting and keeping old specialized industrial equipment going. > This is the world where 8" floppies are not uncommon and I get requests > to retrieve data from old DC300XL QIC carts. Since the controller (and > any interface cards) are part of what makes the equipment go, it just > isn't a matter of getting a new commodity box and installing new > software. If you have a quarter-million invested in a specialized tool, > it pays to keep it going as long as possible. Believe me, I work with vintage equipment too. We keep a library of old equipment in good working order for data transfer, and porting. I have 9-track tape and five disk ][ units about 10 yards from me as I am writing this, so I am hardly unaware of these needs by a long shot. > My point (and I think, Alexey's) is that not everyone uses BSD for > browsing the web and exchanging email. There are still some > applications out there that are still running on the same equipment from > 20 years ago. But do you keep those applications ported to the latest OpenBSD releases? Do you run -current on your 486s? Do you really use a recent OpenBSD version to read QIC carts? If anything Alexey's post proves that people *don't* do these things - he jumped ship when OpenBSD stopped supporting the hardware, even though it would probably have been trivial to fix, (and I am quite interested in what the problem with the SCSI adaptor actually is). > I find that NetBSD's "Of course it runs NetBSD" slogan rings a little > hollow these days. It does, but perhaps there is a reason for that. > Perhaps expecting software to run on both new and old gear isn't > practical. It's not. At the moment we are holding back the potential of the system in order to cater for older machines. Yes, I know I'm going to draw a lot of people's wrath for saying that, but it's true. Whether that is a bad thing or not, I don't know. Maybe it isn't - see my previous post where I defended keeping the ISA drivers around for educational purposes. I don't really know where we're going with this issue, but it's something that needs to be discusses, and I'm glad that we're doing just that, because it's precisely what this list is for. > If that's the case, I'll continue to hang onto my old copies > of distros, the same way that I hang onto copies of MS-DOS, Windows 3.1 > and Windows 98. 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. 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 -patch branch of it for ever more, backporting any new security and other important patches? Frankly, that would probably benefit the community much more than trying to keep the main distribution working on ancient kit forever more. Please don't put too much weight on a comment which was said quite casually as a small part of a much wider discussion. -- Creamy
Re: goodbye to some isa devices
> 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 eventually removed from the tree to clear the way of other changes.
Re: cleanup ossaudio compat
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 reflects your changes to src/lib/libossaudio.
> The comment still doesn't make a lot of sense to me. The comment says
> only 32 devices are available, but OSS_SOUND_MIXER_NRDEVICES is
> defined to be 17. I leave the thinking to somebody else.
> -/* If the NetBSD mixer device should have more than 32 devices
> +/* If the mixer device should have more than 32 devices
> * some will not be available to Linux */
> -#define NETBSD_MAXDEVS 64
> +#define MAX_MIXER_DEVS 64
Based on the comment in the below diff, I think that NETBSD_MAXDEVS used
to be set to 32. Then someone increased it to 64, but forgot to update
the comment. In that case, the "32" in the above comment should be
changed to "MAX_MIXER_DEVS". But perhaps I shouldn't be doing the
thinking either.
Index: ossaudio.c
===
RCS file: /cvs/src/lib/libossaudio/ossaudio.c,v
retrieving revision 1.16
diff -p -u -r1.16 ossaudio.c
--- ossaudio.c 26 Jun 2008 05:42:05 - 1.16
+++ ossaudio.c 27 Mar 2013 18:52:40 -
@@ -456,17 +456,17 @@ audio_ioctl(int fd, unsigned long com, v
}
-/* If the NetBSD mixer device should have more than NETBSD_MAXDEVS devices
+/* If the mixer device should have more than MAX_MIXER_DEVS devices
* some will not be available to Linux */
-#define NETBSD_MAXDEVS 64
+#define MAX_MIXER_DEVS 64
struct audiodevinfo {
int done;
dev_t dev;
ino_t ino;
int16_t devmap[SOUND_MIXER_NRDEVICES],
- rdevmap[NETBSD_MAXDEVS];
- char names[NETBSD_MAXDEVS][MAX_AUDIO_DEV_LEN];
- int enum2opaque[NETBSD_MAXDEVS];
+ rdevmap[MAX_MIXER_DEVS];
+ char names[MAX_MIXER_DEVS][MAX_AUDIO_DEV_LEN];
+ int enum2opaque[MAX_MIXER_DEVS];
u_long devmask, recmask, stereomask;
u_long caps, recsource;
};
@@ -476,7 +476,7 @@ opaque_to_enum(struct audiodevinfo *di,
{
int i, o;
- for (i = 0; i < NETBSD_MAXDEVS; i++) {
+ for (i = 0; i < MAX_MIXER_DEVS; i++) {
o = di->enum2opaque[i];
if (o == opq)
break;
@@ -486,7 +486,7 @@ opaque_to_enum(struct audiodevinfo *di,
break;
}
}
- if (i >= NETBSD_MAXDEVS)
+ if (i >= MAX_MIXER_DEVS)
i = -1;
/*printf("opq_to_enum %s %d -> %d\n", label->name, opq, i);*/
return (i);
@@ -495,7 +495,7 @@ opaque_to_enum(struct audiodevinfo *di,
static int
enum_to_ord(struct audiodevinfo *di, int enm)
{
- if (enm >= NETBSD_MAXDEVS)
+ if (enm >= MAX_MIXER_DEVS)
return (-1);
/*printf("enum_to_ord %d -> %d\n", enm, di->enum2opaque[enm]);*/
@@ -506,7 +506,7 @@ static int
enum_to_mask(struct audiodevinfo *di, int enm)
{
int m;
- if (enm >= NETBSD_MAXDEVS)
+ if (enm >= MAX_MIXER_DEVS)
return (0);
m = di->enum2opaque[enm];
@@ -541,16 +541,10 @@ getdevinfo(int fd)
{ AudioNtreble, SOUND_MIXER_TREBLE },
{ AudioNbass, SOUND_MIXER_BASS },
{ AudioNspeaker,SOUND_MIXER_SPEAKER },
-/* { AudioNheadphone, ?? },*/
{ AudioNoutput, SOUND_MIXER_OGAIN },
{ AudioNinput, SOUND_MIXER_IGAIN },
-/* { AudioNmaster, SOUND_MIXER_SPEAKER },*/
-/* { AudioNstereo, ?? },*/
-/* { AudioNmono, ?? },*/
{ AudioNfmsynth,SOUND_MIXER_SYNTH },
-/* { AudioNwave, SOUND_MIXER_PCM },*/
{ AudioNmidi, SOUND_MIXER_SYNTH },
-/* { AudioNmixerout, ?? },*/
{ 0, -1 }
};
static struct audiodevinfo devcache = { 0 };
@@ -575,12 +569,12 @@ getdevinfo(int fd)
di->caps = 0;
for(i = 0; i < SOUND_MIXER_NRDEVICES; i++)
di->devmap[i] = -1;
- for(i = 0; i < NETBSD_MAXDEVS; i++) {
+ for(i = 0; i < MAX_MIXER_DEVS; i++) {
di->rdevmap[i] = -1;
di->names[i][0] = '\0';
di->enum2opaque[i] = -1;
}
- for(i = 0; i < NETBSD_MAXDEVS; i++) {
+ for(i = 0; i < MAX_MIXER_DEVS; i++) {
mi.index = i;
if (ioctl(fd, AUDIO_MIXER_DEVINFO, &mi) < 0)
break;
@@ -601,7 +595,7 @@ getdevinfo(int fd)
break;
}
}
- for(i = 0; i < NETBSD_MAXDEVS; i++) {
+ for(i = 0; i < MAX_MIXER_DEVS; i++) {
mi.index = i;
if (ioctl(fd, AUDIO_MIXER_DEVINFO, &mi) < 0)
Re: goodbye to some isa devices
> 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 broken (but an FPU is required); second, isa drivers receiving few, if any, attention, doesn't mean they are no longer working. Ever heard of `if it ain't broke, don't touch it'? Or are you just trolling for the sake of it?
Re: goodbye to some isa devices
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, 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, is there any reason for sys/arch/i386/conf/GENERIC to contain these #tr0at isa? port 0xa20 iomem 0xd8000# IBM TROPIC based Token-Ring #tr1at isa? port 0xa24 iomem 0xd# IBM TROPIC based Token-Ring #tr*at isa? # 3COM TROPIC based Token-Ring ?
Re: goodbye to some isa devices
> >> 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, is there any reason for > sys/arch/i386/conf/GENERIC to contain these > > #tr0 at isa? port 0xa20 iomem 0xd8000# IBM TROPIC based Token-Ring > #tr1 at isa? port 0xa24 iomem 0xd# IBM TROPIC based Token-Ring > #tr* at isa? # 3COM TROPIC based Token-Ring > > ? Definitely not, this is a leftover of the token ring pruning. Thanks for noticing!
Re: goodbye to some isa devices
> 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 bit-rot in the tree? > > > > Absolutely not. First, 80486 support is not broken (but an FPU is > > required); > > You mis-understand, I am fully aware that the CPU itself is fully > supported - my point was that it's likely that any 486 as a whole > is more than likely to contain hardware that has issues which are > going un-noticed because people are not using the code. 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 extension boards. Even boards such as ISA xl(4) or eg(4) receive occasional testing several times a year. > > second, isa drivers receiving few, if any, attention, doesn't > > mean they are no longer working. > > Where did I claim that, exactly? ``broken (as I suspected)'', followed by ``suffering bit-rot'' does not exactly convey the idea of something in working condition, does it? > > Ever heard of `if it ain't broke, don't > > touch it'? > > Well, maybe Alexey would have been happy for somebody to touch his > SCSI driver and fix it, why don't you do it for him? Somebody > broke it almost 20 releases ago, and guess what, from what I can > gather it's still broken. I remember very well ahc(4) being broken on older chips for a couple releases because the developer in charge had difficulties getting the code to work with all generations of the chip, but it got better after a few years. There is no evidence the OP has ever tried OpenBSD again after switching operating systems on his system. > > Or are you just trolling for the sake of it? > > I didn't expect that from you, frankly. Other people have been > rude to me off-list, but I thought you were above that. So what? To me, you often sound like a troll.
Re: goodbye to some isa devices
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 bit-rot in the tree? > > Absolutely not. First, 80486 support is not broken (but an FPU is > required); You mis-understand, I am fully aware that the CPU itself is fully supported - my point was that it's likely that any 486 as a whole is more than likely to contain hardware that has issues which are going un-noticed because people are not using the code. > second, isa drivers receiving few, if any, attention, doesn't > mean they are no longer working. Where did I claim that, exactly? > Ever heard of `if it ain't broke, don't > touch it'? Well, maybe Alexey would have been happy for somebody to touch his SCSI driver and fix it, why don't you do it for him? Somebody broke it almost 20 releases ago, and guess what, from what I can gather it's still broken. So, if it IS broken, DO fix it. > Or are you just trolling for the sake of it? I didn't expect that from you, frankly. Other people have been rude to me off-list, but I thought you were above that. Really, this community has an attitude problem - and you *need* more developers, believe me, you shouldn't be trying to scare them away. -- Creamy
Re: goodbye to some isa devices
> 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 extension boards. Even boards such as ISA xl(4) or eg(4) > receive occasional testing several times a year. I think I clearly implied that some of the 'Key' ISA devices would have to stay, when I said '99% of the ISA-related code'. I never said, ISA can cease to exist, nor that 486 support should be removed now. What you're suggesting is a small part of the ISA code in the tree. ...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. Don't worry, I won't bother you with any patches, I know you ignored the last one, even though I fixed it as you mentioned. > > > second, isa drivers receiving few, if any, attention, doesn't > > > mean they are no longer working. > > > > Where did I claim that, exactly? > > ``broken (as I suspected)'', followed by ``suffering bit-rot'' does not > exactly convey the idea of something in working condition, does it? Why is Alexey's HP Netserver running NetBSD, then? You've just had it pointed out to you in another post that there are dregs of the Token Ring support still in the GENERIC config - how many eyes are actually looking at this code? Who claimed that my repeat key patch broke something that was already broken? My comments of broken and suffering bit-rot don't apply to all ISA code, but certainly do to some of it. > > > Ever heard of `if it ain't broke, don't > > > touch it'? > > > > Well, maybe Alexey would have been happy for somebody to touch his > > SCSI driver and fix it, why don't you do it for him? Somebody > > broke it almost 20 releases ago, and guess what, from what I can > > gather it's still broken. > > I remember very well ahc(4) being broken on older chips for a couple > releases because the developer in charge had difficulties getting the > code to work with all generations of the chip, but it got better after a > few years. There is no evidence the OP has ever tried OpenBSD again > after switching operating systems on his system. So that's one 486 user who doesn't care whether OpenBSD supports his system or not. See what I mean? > > > Or are you just trolling for the sake of it? > > > > I didn't expect that from you, frankly. Other people have been > > rude to me off-list, but I thought you were above that. > > So what? To me, you often sound like a troll. 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 views differ from theirs. This represents a small minority of the OpenBSD development community, I know, but if I was really just here to troll, why would I have posted so many patches and fixes in the two weeks that I have been subscribed? Why does it seem like everybody is obsessed with me on this mailing list at times? Ever since I joined, I have seen a flood of hits from OpenBSD based browsers in the logs for the nocrater.com site, even though it's off-line at the moment and re-directing everybody to the mobile site, which is making us look really unprofessional, I know, but I've been spending so much time contributing to this list that I haven't had time to fix it. I've also had private mails quizzing me as to who I am, (who cares, if I'm writing good code?), and general written abuse, mostly off-list. Get a life. -- Creamy
Re: goodbye to some isa 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 -patch branch of it for ever more, backporting any new security and other important patches? Frankly, that would probably benefit the community much more than trying to keep the main distribution working on ancient kit forever more. Please don't put too much weight on a comment which was said quite casually as a small part of a much wider discussion. That's probably the best approach--as long as basic things such as networking protocols don't change too much, I can deal with the build-from-source-branch issue. You can sort of see this business of deprecation creeping in, even though no broad consensus seems to be behind it. For example, the current Linux X86 kernel apparently does not support some VIA IDE controllers (IIRC, VIA 8237?), so my Via Esther thin clients won't boot using it (OpenBSD runs fine, however). So my hat's off to the community for keeping what it does keep. --Chuck
Re: goodbye to some isa devices
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 that typically go with machines of that era are > > > suffering bit-rot in the tree? > > > > Absolutely not. First, 80486 support is not broken (but an FPU is > > required); > > You mis-understand, I am fully aware that the CPU itself is fully > supported - my point was that it's likely that any 486 as a whole > is more than likely to contain hardware that has issues which are > going un-noticed because people are not using the code. > > > second, isa drivers receiving few, if any, attention, doesn't > > mean they are no longer working. > > Where did I claim that, exactly? > > > Ever heard of `if it ain't broke, don't > > touch it'? > > Well, maybe Alexey would have been happy for somebody to touch his > SCSI driver and fix it, why don't you do it for him? Somebody > broke it almost 20 releases ago, and guess what, from what I can > gather it's still broken. > > So, if it IS broken, DO fix it. > > > Or are you just trolling for the sake of it? > > I didn't expect that from you, frankly. Other people have been > rude to me off-list, but I thought you were above that. > > Really, this community has an attitude problem - and you *need* > more developers, believe me, you shouldn't be trying to scare > them away. People who think we have an attitude problem self-evidently will be unlikely to fit in as developers. Or should we dissemble and surprise them with our attitude when they become developers? Because the attitude doesn't change much when one gets the magic decoder ring. Ken > > -- > Creamy >
Re: goodbye to some isa devices
> 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. Don't > worry, I won't bother you with any patches, I know you ignored the > last one, even though I fixed it as you mentioned. s/ignored/postponed for the weekend/. But I can ignore it for real if you prefer. > > > Where did I claim that, exactly? > > > > ``broken (as I suspected)'', followed by ``suffering bit-rot'' does not > > exactly convey the idea of something in working condition, does it? > > Why is Alexey's HP Netserver running NetBSD, then? What does this have to do with this discussion? Why don't you ask him? If, ten years ago, I had gotten a flat tire driving over a hole on some small country road, and I had never driven on that road again, should I assume that the road has not been repaired in ten years? And that other holes have not appeared elsewhere? > So that's one 486 user who doesn't care whether OpenBSD supports his > system or not. See what I mean? No. > 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. If you consider yourself insulted by what I am writing, then you might want to apply your `get a life' advice to yourself as well. Remember, if you try to put too much subtlety or double-entendre in your english, eople may not read what you expect them to read. > I've also had private mails quizzing me as to who I am, > (who cares, if I'm writing good code?), As long as these are small diffs, nobody cares. But we don't take large contributions from anonymous people. > Get a life. I am living in interesting times.
Re: goodbye to some isa devices
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 clear the way of >> > other changes. >> >> And with no TR stack, is there any reason for >> sys/arch/i386/conf/GENERIC to contain these >> >> #tr0 at isa? port 0xa20 iomem 0xd8000# IBM TROPIC based Token-Ring >> #tr1 at isa? port 0xa24 iomem 0xd# IBM TROPIC based Token-Ring >> #tr* at isa? # 3COM TROPIC based Token-Ring >> >> ? > > Definitely not, this is a leftover of the token ring pruning. Thanks for > noticing! btw, if you guys still looking for something to disable in sys/arch/i386/conf/RAMDISK_CD, take a look on these ie0 at isa? port 0x360 iomem 0xd irq 7 # StarLAN and 3C507 le0 at isa? port 0x360 irq 15 drq 6 # IsoLan, NE2100, and DEPCA le* at isapnp?
Re: goodbye to some isa devices
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 views > differ from theirs. This represents a small minority of the OpenBSD > development community, I know, but if I was really just here to troll, > why would I have posted so many patches and fixes in the two weeks > that I have been subscribed? > Too Creamy? > Why does it seem like everybody is obsessed with me on this mailing list > at times? Ever since I joined, I have seen a flood of hits from OpenBSD > based browsers in the logs for the nocrater.com site, even though it's > off-line at the moment and re-directing everybody to the mobile site, > which is making us look really unprofessional, I know, but I've been > spending so much time contributing to this list that I haven't had time > to fix it. I've also had private mails quizzing me as to who I am, > (who cares, if I'm writing good code?), and general written abuse, mostly > off-list. > It's a hard bunch. And people disagree with you. Don't take it so personally. We love you, man.
Re: goodbye to some isa devices
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 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 system from a Goodwill store for $5 some 6 or 7 years ago. I was kinda depressed that it wouldn't boot OpenBSD anymore, but then I wet my pants when I got KA9Q NOS working on it.
Re: goodbye to some isa devices
> 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.
Re: goodbye to some isa devices
> 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 put a sock in it.
Re: goodbye to some isa devices
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 the older ones are AMDs but I'm less likely to ever use them.
Re: SSE4.2 CRC32 question
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 used Ethernet CRC32. -- Christian "naddy" Weisgerber na...@mips.inka.de
ksh SIGFPE
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 === 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 29 Jan 2013 17:21:29 - @@ -341,11 +341,16 @@ evalexpr(Expr_state *es, enum prec prec) break; case O_DIV: case O_DIVASN: + if (vl->val.i == LONG_MIN && vr->val.i == -1) + evalerr(es, ET_STR, "can't represent result"); res = vl->val.i / vr->val.i; break; case O_MOD: case O_MODASN: - res = vl->val.i % vr->val.i; + if (vl->val.i == LONG_MIN && vr->val.i == -1) + res = 0; + else + res = vl->val.i % vr->val.i; break; case O_PLUS: case O_PLUSASN:
Re: ksh SIGFPE
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"); > res = vl->val.i / vr->val.i; > break; I think LONG_MIN / -1 should still be LONG_MIN. We don't give errors for other overflow conditions.
Re: ksh SIGFPE
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 27 Mar 2013 23:13:44 - @@ -341,11 +341,17 @@ evalexpr(Expr_state *es, enum prec prec) break; case O_DIV: case O_DIVASN: - res = vl->val.i / vr->val.i; + if (vl->val.i == LONG_MIN && vr->val.i == -1) + res = LONG_MIN; + else + res = vl->val.i / vr->val.i; break; case O_MOD: case O_MODASN: - res = vl->val.i % vr->val.i; + if (vl->val.i == LONG_MIN && vr->val.i == -1) + res = 0; + else + res = vl->val.i % vr->val.i; break; case O_PLUS: case O_PLUSASN: On Wed, Mar 27, 2013 at 04:06:22PM -0700, Matthew Dempsky wrote: > 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"); > > res = vl->val.i / vr->val.i; > > break; > > I think LONG_MIN / -1 should still be LONG_MIN. We don't give errors > for other overflow conditions.
Re: goodbye to some isa devices
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 system from a Goodwill store for $5 some 6 or 7 years ago. I was kinda depressed that it wouldn't boot OpenBSD anymore, but then I wet my pants when I got KA9Q NOS working on it. That sounds pretty good--most of my EDA and other stuff is run on AMD64. Didn't most of the Linuces drop pre-P2 support some time ago (ie.g. P1, AMD K6, etc.)? It could be that getting the older architectures to work is as simple as recompiling the kernel, but I haven't checked into it. Maybe it would be handy to have a minimum binary distro just sufficient to boot and recompile from source, if need be. So if you've got a 486 or P1 K5, K6, Crusoe or whatever, you could still get there without searching out a more-up-to-date system. --Chuck
Re: ksh SIGFPE
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 -
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
#ifndef SHORT_STRINGS
@@ -346,7 +347,7 @@ static Char *
exp5(Char ***vp, bool ignore)
{
Char *p1, *p2;
-int i = 0;
+int i = 0, l;
p1 = exp6(vp, ignore);
#ifdef EDEBUG
@@ -370,14 +371,22 @@ exp5(Char ***vp, bool ignore)
i = egetn(p2);
if (i == 0)
stderror(ERR_DIV0);
- i = egetn(p1) / i;
+ l = egetn(p1);
+ if (l == INT_MIN && i == -1)
+ i = INT_MIN;
+ else
+ i = l / i;
break;
case '%':
i = egetn(p2);
if (i == 0)
stderror(ERR_MOD0);
- i = egetn(p1) % i;
+ l = egetn(p1);
+ if (l == INT_MIN && i == -1)
+ i = 0;
+ else
+ i = l % i;
break;
}
xfree((ptr_t) p1);
On Wed, Mar 27, 2013 at 11:15:44PM +, Nicholas Marriott wrote:
> 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.c1 Jun 2009 19:00:57 - 1.21
> +++ expr.c27 Mar 2013 23:13:44 -
> @@ -341,11 +341,17 @@ evalexpr(Expr_state *es, enum prec prec)
> break;
> case O_DIV:
> case O_DIVASN:
> - res = vl->val.i / vr->val.i;
> + if (vl->val.i == LONG_MIN && vr->val.i == -1)
> + res = LONG_MIN;
> + else
> + res = vl->val.i / vr->val.i;
> break;
> case O_MOD:
> case O_MODASN:
> - res = vl->val.i % vr->val.i;
> + if (vl->val.i == LONG_MIN && vr->val.i == -1)
> + res = 0;
> + else
> + res = vl->val.i % vr->val.i;
> break;
> case O_PLUS:
> case O_PLUSASN:
>
>
> On Wed, Mar 27, 2013 at 04:06:22PM -0700, Matthew Dempsky wrote:
> > 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");
> > > res = vl->val.i / vr->val.i;
> > > break;
> >
> > I think LONG_MIN / -1 should still be LONG_MIN. We don't give errors
> > for other overflow conditions.
Re: ksh SIGFPE
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 shell semantics match the C language semantics, but then C semantics for LONG_MIN / -1 and LONG_MIN % -1 appear to be undefined*... so there's nothing to match really. (* The glibc manual claims C requires "LONG_MIN % -1" to evaluate to 0, but my reading of C11 6.5.5.6 says since LONG_MIN / -1 is not representable, that the behavior of LONG_MIN % -1 is undefined.)
Re: ksh SIGFPE
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 dash give SIGFPE too actually. Bash on Ubuntu (4.2.37) plus bash (4.2.45) and zsh (5.0.0) from our ports. > > Checking POSIX, I notice that it requires that shell semantics match > the C language semantics, but then C semantics for LONG_MIN / -1 and > LONG_MIN % -1 appear to be undefined*... so there's nothing to match > really. > > (* The glibc manual claims C requires "LONG_MIN % -1" to evaluate to > 0, but my reading of C11 6.5.5.6 says since LONG_MIN / -1 is not > representable, that the behavior of LONG_MIN % -1 is undefined.)
subr poison
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/kern/kern_malloc.c,v
retrieving revision 1.97
diff -u -p -r1.97 kern_malloc.c
--- kern/kern_malloc.c 26 Mar 2013 16:36:01 - 1.97
+++ kern/kern_malloc.c 27 Mar 2013 23:32:50 -
@@ -132,48 +132,14 @@ const long addrmask[] = { 0,
};
/*
- * The WEIRD_ADDR is used as known text to copy into free objects so
+ * The FREELIST_MARKER is used as known text to copy into free objects so
* that modifications after frees can be detected.
*/
#ifdef DEADBEEF0
-#define WEIRD_ADDR ((unsigned) DEADBEEF0)
+#define FREELIST_MARKER((unsigned) DEADBEEF0)
#else
-#define WEIRD_ADDR ((unsigned) 0xdeadbeef)
+#define FREELIST_MARKER((unsigned) 0xdeadbeef)
#endif
-#define POISON_SIZE32
-
-static void
-poison(void *v, size_t len)
-{
- uint32_t *ip = v;
- size_t i;
-
- if (len > POISON_SIZE)
- len = POISON_SIZE;
- len = len / sizeof(*ip);
- for (i = 0; i < len; i++) {
- ip[i] = WEIRD_ADDR;
- }
-}
-
-static size_t
-poison_check(void *v, size_t len)
-{
-
- uint32_t *ip = v;
- size_t i;
-
- if (len > POISON_SIZE)
- len = POISON_SIZE;
- len = len / sizeof(*ip);
- for (i = 0; i < len; i++) {
- if (ip[i] != WEIRD_ADDR) {
- return i;
- }
- }
- return -1;
-}
-
#endif /* DIAGNOSTIC */
@@ -195,7 +161,6 @@ malloc(unsigned long size, int type, int
int s;
caddr_t va, cp;
#ifdef DIAGNOSTIC
- size_t pidx;
int freshalloc;
char *savedtype;
#endif
@@ -300,7 +265,7 @@ malloc(unsigned long size, int type, int
* Copy in known text to detect modification
* after freeing.
*/
- poison(cp, allocsize);
+ poison_mem(cp, allocsize);
freep->kf_type = M_FREE;
#endif /* DIAGNOSTIC */
SIMPLEQ_INSERT_HEAD(&kbp->kb_freelist, freep, kf_flist);
@@ -337,18 +302,19 @@ malloc(unsigned long size, int type, int
}
}
- /* Fill the fields that we've used with WEIRD_ADDR */
- poison(freep, sizeof(*freep));
+ /* Fill the fields that we've used with poison */
+ poison_mem(freep, sizeof(*freep));
/* and check that the data hasn't been modified. */
if (freshalloc == 0) {
- if ((pidx = poison_check(va, allocsize)) != -1) {
- printf("%s %zd of object %p size 0x%lx %s %s"
+ size_t pidx;
+ int pval;
+ if (poison_check(va, allocsize, &pidx, &pval)) {
+ panic("%s %zd of object %p size 0x%lx %s %s"
" (0x%x != 0x%x)\n",
"Data modified on freelist: word",
pidx, va, size, "previous type",
- savedtype, ((int32_t*)va)[pidx], WEIRD_ADDR);
- panic("boom");
+ savedtype, ((int32_t*)va)[pidx], pval);
}
}
@@ -447,7 +413,7 @@ free(void *addr, int type)
* Check for multiple frees. Use a quick check to see if
* it looks free before laboriously searching the freelist.
*/
- if (freep->kf_spare0 == WEIRD_ADDR) {
+ if (freep->kf_spare0 == FREELIST_MARKER) {
struct kmem_freelist *fp;
SIMPLEQ_FOREACH(fp, &kbp->kb_freelist, kf_flist) {
if (addr != fp)
@@ -462,7 +428,8 @@ free(void *addr, int type)
* so we can list likely culprit if modification is detected
* when the object is reallocated.
*/
- poison(addr, size);
+ poison_mem(addr, size);
+ freep->kf_spare0 = FREELIST_MARKER;
freep->kf_type = type;
#endif /* DIAGNOSTIC */
Index: kern/subr_poison.c
===
RCS file: kern/subr_poison.c
diff -N kern/subr_poison.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ kern/subr_poison.c 27 Mar 2013 23:34:13 -
@@ -0,0 +1,64 @@
+/* $OpenBSD */
+/*
+ * Copyright (c) 2013 Ted Unangst
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIR
Re: ksh SIGFPE
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 go
ahead. So I don't see why we need to follow it. I don't see anything
specified in SUSv3 at least.
Index: expr.c
===
RCS file: /cvs/src/bin/expr/expr.c,v
retrieving revision 1.17
diff -u -p -r1.17 expr.c
--- expr.c 21 Jun 2006 18:28:24 - 1.17
+++ expr.c 27 Mar 2013 23:45:42 -
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -329,9 +330,13 @@ eval4(void)
errx(2, "division by zero");
}
if (op == DIV) {
- l->u.i /= r->u.i;
+ if (l->u.i != INT_MIN || r->u.i != -1)
+ l->u.i /= r->u.i;
} else {
- l->u.i %= r->u.i;
+ if (l->u.i != INT_MIN || r->u.i != -1)
+ l->u.i %= r->u.i;
+ else
+ l->u.i = 0;
}
}
On Wed, Mar 27, 2013 at 11:26:23PM +, Nicholas Marriott wrote:
> 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 -
> @@ -32,6 +32,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #ifndef SHORT_STRINGS
> @@ -346,7 +347,7 @@ static Char *
> exp5(Char ***vp, bool ignore)
> {
> Char *p1, *p2;
> -int i = 0;
> +int i = 0, l;
>
> p1 = exp6(vp, ignore);
> #ifdef EDEBUG
> @@ -370,14 +371,22 @@ exp5(Char ***vp, bool ignore)
> i = egetn(p2);
> if (i == 0)
> stderror(ERR_DIV0);
> - i = egetn(p1) / i;
> + l = egetn(p1);
> + if (l == INT_MIN && i == -1)
> + i = INT_MIN;
> + else
> + i = l / i;
> break;
>
> case '%':
> i = egetn(p2);
> if (i == 0)
> stderror(ERR_MOD0);
> - i = egetn(p1) % i;
> + l = egetn(p1);
> + if (l == INT_MIN && i == -1)
> + i = 0;
> + else
> + i = l % i;
> break;
> }
> xfree((ptr_t) p1);
>
>
>
> On Wed, Mar 27, 2013 at 11:15:44PM +, Nicholas Marriott wrote:
> > 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 27 Mar 2013 23:13:44 -
> > @@ -341,11 +341,17 @@ evalexpr(Expr_state *es, enum prec prec)
> > break;
> > case O_DIV:
> > case O_DIVASN:
> > - res = vl->val.i / vr->val.i;
> > + if (vl->val.i == LONG_MIN && vr->val.i == -1)
> > + res = LONG_MIN;
> > + else
> > + res = vl->val.i / vr->val.i;
> > break;
> > case O_MOD:
> > case O_MODASN:
> > - res = vl->val.i % vr->val.i;
> > + if (vl->val.i == LONG_MIN && vr->val.i == -1)
> > + res = 0;
> > + else
> > + res = vl->val.i % vr->val.i;
> > break;
> > case O_PLUS:
> > case O_PLUSASN:
> >
> >
> > On Wed, Mar 27, 2013 at 04:06:22PM -0700, Matthew Dempsky wrote:
> > > 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");
> > > > res = vl->val.i / vr->val.i;
> > > > break;
> > >
> > > I think LONG_MIN / -1 should still be LONG_MIN. We don't give errors
> > > for other overflow conditions.
Re: goodbye to some isa devices
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: /cvs/src/sys/arch/i386/conf/GENERIC,v ... > -pcmcia* at tcic? I really can't comment. Haven't had much luck with PCMCIA lately. Haven't cared enough to, uh..care. > -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers this driver doesn't work anyway, or at least it didn't, somewhere over ten years ago when I last tried. If it did work, you wouldn't want it to. It was intended for things like scanners and other really slow things. > -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 > controllers > -#wds1at isa? port 0x358 irq 11 drq 5 I've never seen one of these. That says something. Not sure what. > -eg0 at isa? disable port 0x310 irq 5# 3C505/Etherlink+ ethernet This is an incredibly rare, huge, power hungry NIC. I've got one, I think. Never tested it. It came from the store I worked at, we tried to sell them for $600-$700 each, back in the mid 1980s. The one I think I have is the store demo, we never sold any. It was kinda cool in that it was a 16 bit card with its own 80186 CPU on it...but for use, it is uninteresting. > -el0 at isa? disable port 0x300 irq 9# 3C501 ethernet This is probably the worst Ethernet card ever built and sold. Apparently, it has ONE buffer, which can be receiving data, sending data, or dropping data when switching between the two modes. IF anyone in the U.S. is running a 3c501 or a 3c505 and is upset with this being removed. I'll send you a 3c509B. You will be very happy with it. None of this stuff will be missed by users. The only question would be the tcic, I don't know what it would be in. I suspect it would be a non-issue, it's probably old enough to be in laptops which were rarely expanded to 32M RAM. There is a lot of ISA stuff I'd object to removing from the kernel; none of this is it. I'm entirely ok with this stuff going... Nick.
[PATCH] Potential bug fix for opencvs annotate
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
namecache and bpf
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 === RCS file: /cvs/src/sys/kern/vfs_init.c,v retrieving revision 1.30 diff -u -p -r1.30 vfs_init.c --- kern/vfs_init.c 23 Aug 2012 06:12:49 - 1.30 +++ kern/vfs_init.c 28 Mar 2013 02:50:20 - @@ -39,6 +39,7 @@ #include #include +#include #include #include #include Index: sys/vnode.h === RCS file: /cvs/src/sys/sys/vnode.h,v retrieving revision 1.113 diff -u -p -r1.113 vnode.h --- sys/vnode.h 8 Oct 2012 15:43:08 - 1.113 +++ sys/vnode.h 28 Mar 2013 02:48:29 - @@ -39,7 +39,6 @@ #include #include #include -#include #include #include
libkvm page size handling
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 testing.
Index: kvm_alpha.c
===
RCS file: /cvs/src/lib/libkvm/kvm_alpha.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 kvm_alpha.c
--- kvm_alpha.c 20 Mar 2006 15:11:48 - 1.14
+++ kvm_alpha.c 23 Mar 2013 16:39:53 -
@@ -113,10 +113,6 @@ _kvm_kvatop(kvm_t *kd, u_long va, paddr_
vm = kd->vmst;
page_off = va & (cpu_kh->page_size - 1);
-#ifndef PAGE_SHIFT
-#definePAGE_SHIFT vm->page_shift
-#endif
-
if (va >= ALPHA_K0SEG_BASE && va <= ALPHA_K0SEG_END) {
/*
* Direct-mapped address: just convert it.
Index: kvm_amd64.c
===
RCS file: /cvs/src/lib/libkvm/kvm_amd64.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 kvm_amd64.c
--- kvm_amd64.c 5 Dec 2012 23:20:02 - 1.9
+++ kvm_amd64.c 23 Mar 2013 16:39:25 -
@@ -96,11 +96,11 @@ _kvm_kvatop(kvm_t *kd, u_long va, paddr_
return (0);
}
- page_off = va & PAGE_MASK;
+ page_off = va & (kd->nbpg - 1);
if (va >= PMAP_DIRECT_BASE && va <= PMAP_DIRECT_END) {
*pa = va - PMAP_DIRECT_BASE;
- return (int)(PAGE_SIZE - page_off);
+ return (int)(kd->nbpg - page_off);
}
cpu_kh = kd->cpu_data;
@@ -177,7 +177,7 @@ _kvm_kvatop(kvm_t *kd, u_long va, paddr_
goto lose;
}
*pa = (pte & PG_FRAME) + page_off;
- return (int)(PAGE_SIZE - page_off);
+ return (int)(kd->nbpg - page_off);
lose:
*pa = (u_long)~0L;
Index: kvm_arm.c
===
RCS file: /cvs/src/lib/libkvm/kvm_arm.c,v
retrieving revision 1.7
diff -u -p -u -r1.7 kvm_arm.c
--- kvm_arm.c 20 Mar 2013 14:46:45 - 1.7
+++ kvm_arm.c 23 Mar 2013 16:39:19 -
@@ -106,7 +106,7 @@ _kvm_kvatop(kvm_t *kd, u_long va, paddr_
va < cpup->kernelbase + cpup->kerneloffs + cpup->staticsize) {
*pa = (va - cpup->kernelbase) +
(paddr_t)cpup->ram_segs[0].start;
- return (int)(PAGE_SIZE - (va & PAGE_MASK));
+ return (int)(kd->nbpg - (va & (kd->nbpg - 1)));
}
_kvm_err(kd, 0, "kvm_vatop: va %x unreachable", va);
Index: kvm_hppa.c
===
RCS file: /cvs/src/lib/libkvm/kvm_hppa.c,v
retrieving revision 1.7
diff -u -p -u -r1.7 kvm_hppa.c
--- kvm_hppa.c 28 Jul 2009 12:56:25 - 1.7
+++ kvm_hppa.c 23 Mar 2013 16:39:13 -
@@ -63,7 +63,7 @@ _kvm_kvatop(kvm_t *kd, u_long va, paddr_
/* XXX this only really works for the kernel image only */
*pa = va;
- return (PAGE_SIZE - (va & PAGE_MASK));
+ return (kd->nbpg - (va & (kd->nbpg - 1)));
}
/*
Index: kvm_hppa64.c
===
RCS file: /cvs/src/lib/libkvm/kvm_hppa64.c,v
retrieving revision 1.1
diff -u -p -u -r1.1 kvm_hppa64.c
--- kvm_hppa64.c9 Jul 2011 00:29:59 - 1.1
+++ kvm_hppa64.c23 Mar 2013 16:39:05 -
@@ -63,7 +63,7 @@ _kvm_kvatop(kvm_t *kd, u_long va, paddr_
/* XXX this only really works for the kernel image only */
*pa = va;
- return (PAGE_SIZE - (va & PAGE_MASK));
+ return (kd->nbpg - (va & (kd->nbpg - 1)));
}
/*
Index: kvm_i386.c
===
RCS file: /cvs/src/lib/libkvm/kvm_i386.c,v
retrieving revision 1.22
diff -u -p -u -r1.22 kvm_i386.c
--- kvm_i386.c 9 Jul 2012 08:43:10 - 1.22
+++ kvm_i386.c 23 Mar 2013 16:38:56 -
@@ -101,10 +101,10 @@ _kvm_initvtop(kvm_t *kd)
(off_t)_kvm_pa2off(kd, nl[0].n_value - KERNBASE)) != sizeof pa)
goto invalid;
- vm->PTD = (pd_entry_t *)_kvm_malloc(kd, PAGE_SIZE);
+ vm->PTD = (pd_entry_t *)_kvm_malloc(kd, kd->nbpg);
- if (_kvm_pread(kd, kd->pmfd, vm->PTD, PAGE_SIZE,
- (off_t)_kvm_pa2off(kd, pa)) != PAGE_SIZE)
+ if (_kvm_pread(kd, kd->pmfd, vm->PTD, kd->nbpg,
+ (off_t)_kvm_pa2off(kd, pa)) != kd->nbpg)
goto invalid;
return (0);
@@ -138,7 +138,7 @@ _kvm_kvatop(kvm_t *kd, u_long va, paddr_
}
vm = kd->vmst;
- offset = va & PAGE_MASK;
+ offset = va & (kd->nbpg - 1);
/*
* If we are initializing (kernel page table descriptor pointer
@@ -146,7 +146,7 @@ _kvm_kvatop(kvm_t *kd, u_long va, paddr_
*/
if (vm->PTD == NULL) {
*pa = va;
- return (PAGE_SIZE - (int)offset);
+
Re: goodbye to some isa devices
> > 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* examples of this. I disagree. I'd agree with ``and they are more likely to get broken as a result''. > > But we don't take large > > contributions from anonymous people. > > Anonymous? How do I know 'Miod' is your real name? Why do I need to know? It is not my real name, it is only my first name. You aren't using a last name, and you're unlikely to be one of the few person who actually don't have any, hence you're anonymous. > Really, I hope this flame war is all a big mis-understanding. You can't say in substance "it's a pity OpenBSD doesn't support the VAX 11/780 anymore" in one mail, "you guys really ought to ditch floppy installation media" in another, and expect people not to question your logic or your motives.
