Re: goodbye to some isa devices
On 03/27/13 21:14, Creamy wrote: On Wed, Mar 27, 2013 at 08:05:47PM +, Miod Vallat wrote: 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. You make some valid points, but I also agree you seem a tad trollish at times, and your choice of name does not improve the feeling. Maybe you are, maybe you aren't (or believe you aren't), but that's how I, and as it seems, others, feel. I really can't remember anyone feeling offended by miod before. Maybe that's a hint. I dunno. Acting butthurt on this list, justified or not, has never helped anyone though. /Alexander
Re: goodbye to some isa devices
Nick Holland nick at holland-consulting.net writes: 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... How about this one? ie0 at isa? port 0x360 iomem 0xd irq 7 # StarLAN and 3C507 Looking at sys/dev/isa/if_ie.c shows different pieces of code glued together and it is relative big (~2000 LOC).
Re: goodbye to some isa devices
On 28.03.2013, at 13:17, Daniel Bolgheroni dan...@bolgh.eng.br wrote: On Thu, Mar 28, 2013 at 05:46:30AM +, Miod Vallat wrote: 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. Agreed. I read all this thread and couldn't figure it out what this guy really wants. To be quite frank, your statement is even more ambiguous and could be easily misinterpreted as 'trollish' in nature. Here, asking questions is considered a waste of many people's time, yet some always feel obligated to point out just how much of their precious time is actually being wasted. Redundancy and impoliteness ensue. Ask any psychologist what makes humans special and they will tell you it is the ability to ask questions in order to enrich their complex existence. Deal with it. And keep your ISA support, because nobody is going to take it away from you by asking 'stupid' questions. I really don't get it why it invokes so many hard feelings. And kudos to Nick for being the calmest and most helpful person in this discussion. Keep it up.
Re: goodbye to some isa devices
please everyone, move this to misc@ if you want to continue, or just drop the thread.
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 cre...@nocrater.com wrote: but I honestly question the utility of any of these ISA network and SCSI drivers. Perhaps somebody who is new to coding might be able to learn something from them? There is such a vast amount of code in the different BSD 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 cre...@nocrater.com wrote: Looking to the future, when are we going to drop 486 support, anyway? Now, that's a more interesting thing ask. How much of the hardware survives now, anyway? I mean at least the old Vaxen were, (and are), maintainable. 486 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: 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 cre...@nocrater.com wrote: Looking to the future, when are we going to drop 486 support, anyway? Now, that's a more interesting thing ask. How much of the hardware survives now, anyway? I mean at least the old Vaxen were, (and are), maintainable. 486 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
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
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 m...@online.fr 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 m...@online.fr 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
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 ma1l1i...@yahoo.co.uk 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: 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.
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.
Re: goodbye to some isa devices
Date: Tue, 26 Mar 2013 05:20:27 -0400 From: Ted Unangst t...@tedunangst.com These isa devs are already disabled and not particularly popular among our users. affected: tcic, sea, wds, eg, el The reason these devices are disabled is probably that their probe routines are destructive. So the fact that they are disabled doesn't necessarily mean that they don't work properly. 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. Index: arch/i386/conf/GENERIC === RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v retrieving revision 1.744 diff -u -p -r1.744 GENERIC --- arch/i386/conf/GENERIC15 Mar 2013 09:10:52 - 1.744 +++ arch/i386/conf/GENERIC26 Mar 2013 08:20:40 - @@ -188,7 +188,6 @@ nvt* at iic? # Novoton W83795G pcic0at isa? port 0x3e0 iomem 0xd iosiz 0x1 pcic1at isa? port 0x3e2 iomem 0xe iosiz 0x4000 pcic2at isa? port 0x3e4 iomem 0xe iosiz 0x4000 -tcic0at isa? disable port 0x240 iomem 0xd iosiz 0x1 # ISA Plug-and-Play PCMCIA controllers #option DEBUG_ISAPNP @@ -199,7 +198,6 @@ pcic* at pci? # PCMCIA bus support pcmcia* at pcic? -pcmcia* at tcic? # CardBus bus support cardbus* at cardslot? @@ -464,13 +462,10 @@ siop* at pci? # NCR 538XX SCSI control adv* at pci? # AdvanSys 1200A/B and ULTRA SCSI adw* at pci? # AdvanSys ULTRA WIDE SCSI pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers trm* at pci? # Tekram DC-3x5U SCSI Controllers uha0 at isa? port 0x330 # UltraStor [13]4f SCSI controllers uha1 at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers uha* at eisa?# UltraStor 24f SCSI controllers -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 controllers -#wds1at isa? port 0x358 irq 11 drq 5 scsibus* at scsi? sd* at scsibus? # SCSI disk drives @@ -511,8 +506,6 @@ ne0 at isa? port 0x240 irq 9# NE[12]00 ne1 at isa? port 0x300 irq 10 # NE[12]000 ethernet ne2 at isa? port 0x280 irq 9# NE[12]000 ethernet ne* at isapnp? # NE[12]000 PnP ethernet -eg0 at isa? disable port 0x310 irq 5# 3C505/Etherlink+ ethernet -el0 at isa? disable port 0x300 irq 9# 3C501 ethernet ep0 at isa? # 3C509 ethernet ep* at isapnp? # 3C509 PnP ethernet ep* at isa? # 3C509 ethernet Index: arch/i386/conf/RAMDISK_CD === RCS file: /cvs/src/sys/arch/i386/conf/RAMDISK_CD,v retrieving revision 1.194 diff -u -p -r1.194 RAMDISK_CD --- arch/i386/conf/RAMDISK_CD 16 Nov 2012 02:15:38 - 1.194 +++ arch/i386/conf/RAMDISK_CD 26 Mar 2013 08:19:13 - @@ -223,13 +223,11 @@ siop* at pci? # NCR 538XX SCSI control adv* at pci? # AdvanSys 1200A/B and ULTRA SCSI adw* at pci? # AdvanSys ULTRA WIDE SCSI pcscp* at pci? # AMD 53c974 PCscsi-PCI SCSI -sea0 at isa? disable iomem 0xc8000 irq 5 # Seagate ST0[12] SCSI controllers trm* at pci? # Tekram DC-3x5U SCSI Controllers uha0 at isa? port 0x330 # UltraStor [13]4f SCSI controllers uha1 at isa? disable port 0x334 # UltraStor [13]4f SCSI controllers uha* at eisa?# UltraStor 24f SCSI controllers -wds0 at isa? disable port 0x350 irq 15 drq 6 # WD7000 and TMC-7000 controllers -#wds1at isa? port 0x358 irq 11 drq 5 + softraid0at root # Software RAID # I2O @@ -272,8 +270,6 @@ ne0 at isa? port 0x240 irq 9# NE[12]000 ne1 at isa? port 0x300 irq 10 # NE[12]000 ethernet ne2 at isa? port 0x280 irq 9# NE[12]000 ethernet ne* at isapnp? # NE[12]000 PnP ethernet -eg0 at isa? disable port 0x310 irq 5 # 3C505/Etherlink+ ethernet -el0 at isa? disable port 0x300 irq 9 # 3C501 ethernet ep0 at isa? # 3C509 ethernet ep* at isa? # 3C509 ethernet ep* at isapnp? # 3C509 PnP ethernet Index: arch/i386/conf/files.i386 === RCS file: /cvs/src/sys/arch/i386/conf/files.i386,v retrieving revision 1.211 diff -u -p -r1.211 files.i386 --- arch/i386/conf/files.i386 6 Sep 2012 20:20:30 - 1.211 +++ arch/i386/conf/files.i386 26 Mar 2013 08:19:33 - @@ -362,12 +362,6 @@ file dev/isa/i82365_isapnp.c
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: Date: Tue, 26 Mar 2013 05:20:27 -0400 From: Ted Unangst t...@tedunangst.com These isa devs are already disabled and not particularly popular among our users. affected: tcic, sea, wds, eg, el The reason these devices are disabled is probably that their probe routines are destructive. So the fact that they are disabled doesn't necessarily mean that they don't work properly. 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. Perfection is achieved when there's nothing left to take away. :) It's not so much that we spend time maintaining the source, but I do spend time compiling it. And I have to download it (3 times!) every time I install a new snapshot. Cumulatively, I've probably spent hours of my life waiting for these drivers' bits to go from here to there. I will selfishly claim that if I save five minutes of time this year by not compiling these files, that right there is more benefit than retaining support. I targeted disabled devices figuring they were least likely to be missed, but I honestly question the utility of any of these ISA network and SCSI drivers. They're going to be slow as shit. Besides, at this point, due to adding so many new drivers (kernel size has more than doubled in last ten years) the minimum RAM requirement is basically past ISA only machines. The segment of machines that lack PCI but support 32M or more of RAM is very narrow. And unlike sparc or vax, I don't think running OpenBSD on some ancient 486 is historically interesting.
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 5:09 PM, Ted Unangst t...@tedunangst.com wrote: On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: Date: Tue, 26 Mar 2013 05:20:27 -0400 From: Ted Unangst t...@tedunangst.com These isa devs are already disabled and not particularly popular among our users. affected: tcic, sea, wds, eg, el The reason these devices are disabled is probably that their probe routines are destructive. So the fact that they are disabled doesn't necessarily mean that they don't work properly. 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. Perfection is achieved when there's nothing left to take away. :) It's not so much that we spend time maintaining the source, but I do spend time compiling it. And I have to download it (3 times!) every time I install a new snapshot. Cumulatively, I've probably spent hours of my life waiting for these drivers' bits to go from here to there. I will selfishly claim that if I save five minutes of time this year by not compiling these files, that right there is more benefit than retaining support. I targeted disabled devices figuring they were least likely to be missed, but I honestly question the utility of any of these ISA network and SCSI drivers. They're going to be slow as shit. Besides, at this point, due to adding so many new drivers (kernel size has more than doubled in last ten years) the minimum RAM requirement is basically past ISA only machines. The segment of machines that lack PCI but support 32M or more of RAM is very narrow. And unlike sparc or vax, I don't think running OpenBSD on some ancient 486 is historically interesting. I still run OpenBSD as a wireless AP on a pentium-1 166Mhz with 48Mb RAM, and 3 PCI cards. ISA sound card was removed :-) -- Brightest day, Blackest night, No bug shall escape my sight, And those who worship evil's mind, be wary of my powers, puffy lantern's light !
Re: goodbye to some isa devices
On Tue, Mar 26, 2013 at 09:09:14AM -0400, Ted Unangst wrote: On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: Date: Tue, 26 Mar 2013 05:20:27 -0400 From: Ted Unangst t...@tedunangst.com These isa devs are already disabled and not particularly popular among our users. affected: tcic, sea, wds, eg, el The reason these devices are disabled is probably that their probe routines are destructive. So the fact that they are disabled doesn't necessarily mean that they don't work properly. 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. Perfection is achieved when there's nothing left to take away. :) It's not so much that we spend time maintaining the source, but I do spend time compiling it. And I have to download it (3 times!) every time I install a new snapshot. Cumulatively, I've probably spent hours of my life waiting for these drivers' bits to go from here to there. I will selfishly claim that if I save five minutes of time this year by not compiling these files, that right there is more benefit than retaining support. I targeted disabled devices figuring they were least likely to be missed, but I honestly question the utility of any of these ISA network and SCSI drivers. They're going to be slow as shit. Besides, at this point, due to adding so many new drivers (kernel size has more than doubled in last ten years) the minimum RAM requirement is basically past ISA only machines. The segment of machines that lack PCI but support 32M or more of RAM is very narrow. And unlike sparc or vax, I don't think running OpenBSD on some ancient 486 is historically interesting. The ISA SCSI drivers have certainly received no love from me as a deliberate policy. This of course may be good or bad for their functionality. :-) And then there are the EISA SCSI drivers. Ken
Re: goodbye to some isa devices
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.
Re: goodbye to some isa devices
Date: Tue, 26 Mar 2013 09:09:14 -0400 From: Ted Unangst t...@tedunangst.com On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: Date: Tue, 26 Mar 2013 05:20:27 -0400 From: Ted Unangst t...@tedunangst.com These isa devs are already disabled and not particularly popular among our 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 they are disabled doesn't necessarily mean that they don't work properly. 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. Perfection is achieved when there's nothing left to take away. :) It's not so much that we spend time maintaining the source, but I do spend time compiling it. And I have to download it (3 times!) every time I install a new snapshot. Cumulatively, I've probably spent hours of my life waiting for these drivers' bits to go from here to there. I will selfishly claim that if I save five minutes of time this year by not compiling these files, that right there is more benefit than retaining support. I targeted disabled devices figuring they were least likely to be missed, but I honestly question the utility of any of these ISA network and SCSI drivers. They're going to be slow as shit. Besides, at this point, due to adding so many new drivers (kernel size has more than doubled in last ten years) the minimum RAM requirement is basically past ISA only machines. The segment of machines that lack PCI but support 32M or more of RAM is very narrow. And unlike sparc or vax, I don't think running OpenBSD on some ancient 486 is historically interesting. Probably true. I'm not necessarily opposed. Although it would make me sad if we didn't run on a machine that some other OS would still support.
Re: goodbye to some isa devices
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 anyway? Yes, I've read the FAQ, and I know we're all supposed to be using the GENERIC kernel, but who does? Mine is customisted beyond recognition. And I have to download it (3 times!) every time I install a new snapshot. Cumulatively, I've probably spent hours of my life waiting for these drivers' bits to go from here to there. I will selfishly claim that if I save five minutes of time this year by not compiling these files, that right there is more benefit than retaining support. There is certainly a case that five minutes multiplied by the number of OpenBSD users does add up to a significant amount of wasted time, but why are you assuming that these disabled by default drivers are not used by a significant number of people? I targeted disabled devices figuring they were least likely to be missed, I disagree here, there are plenty of enabled devices that nobody owns or cares about. The two issues are completely separate. 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? Besides, at this point, due to adding so many new drivers (kernel size has more than doubled in last ten years) the minimum RAM requirement is basically past ISA only machines. This is an issue for the install media. After that, you should be running a custom kernel if you're using an obsolete machine. The segment of machines that lack PCI but support 32M or more of RAM is very narrow. True. And unlike sparc or vax, I don't think running OpenBSD on some ancient 486 is historically interesting. But OpenBSD doesn't run on the really interesting Vaxen, anyway. If it did, I'd have an 11-series Vax here tomorrow. I even have some 9-track tape in the loft, just waiting for it. The truth is, running OpenBSD on a MicroVax, is no more fun than an old 486, it's just slower. boot loginout.exe oh, what nostalgia. Not. Have you ever used those machines, with their crashing removable disk packs. and tape drives that unwound 2400 feet of tape all over the place in just a few seconds? You're seeing them through rose-tinted glasses if you did. Not to mention that the decent Vaxen need three phase power. Great. Looking to the future, when are we going to drop 486 support, anyway? -- Creamy
Re: goodbye to some isa devices
Penned by Ted Unangst on 20130326 8:09.14, we have: | On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote: | Date: Tue, 26 Mar 2013 05:20:27 -0400 | From: Ted Unangst t...@tedunangst.com | | These isa devs are already disabled and not particularly popular among | our users. affected: tcic, sea, wds, eg, el | | The reason these devices are disabled is probably that their probe | routines are destructive. So the fact that they are disabled doesn't | necessarily mean that they don't work properly. | | 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. | | Perfection is achieved when there's nothing left to take away. :) | | It's not so much that we spend time maintaining the source, but I do | spend time compiling it. And I have to download it (3 times!) every | time I install a new snapshot. Cumulatively, I've probably spent hours | of my life waiting for these drivers' bits to go from here to there. I | will selfishly claim that if I save five minutes of time this year by | not compiling these files, that right there is more benefit than | retaining support. | | I targeted disabled devices figuring they were least likely to be | missed, but I honestly question the utility of any of these ISA | network and SCSI drivers. They're going to be slow as shit. Besides, | at this point, due to adding so many new drivers (kernel size has | more than doubled in last ten years) the minimum RAM requirement is | basically past ISA only machines. The segment of machines that lack | PCI but support 32M or more of RAM is very narrow. And unlike sparc or | vax, I don't think running OpenBSD on some ancient 486 is historically | interesting. I have some of these devices actually. Haven't used them in a few years, mainly due to office moves and boxes of unpacked unsorted stuff. I do clearly recall that it is useful to only enable some isa devices if one has them. I guess the question is, are we moving to a world where isa is not supported and/or supportable? Sure, if I'm doing build tests I'm going to load a box with mem and the fastest disks and nics I have. 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. 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? Thanks, -- Todd Fries .. t...@fries.net |\ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC\ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com\ 1.866.792.3418 (FAX) | PO Box 16169, Oklahoma City, OK 73113 \ sip:freedae...@ekiga.net | ..in support of free software solutions. \ sip:4052279...@ekiga.net \ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt
Re: goodbye to some isa devices
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.
Re: goodbye to some isa devices
On Mar 26, 2013, at 6:26 PM, Creamy cre...@nocrater.com wrote: but I honestly question the utility of any of these ISA network and SCSI drivers. Perhaps somebody who is new to coding might be able to learn something from them? There is such a vast amount of code in the different BSD 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? 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. Looking to the future, when are we going to drop 486 support, anyway? Now, that's a more interesting thing ask.
Re: goodbye to some isa devices
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 know the locator information, so you are making a decision for others. Same thing with the stanzas in dev/isa/files.isa; if you remove those then noone else can ever use the code. If that is your goal, look at it this way. You talk about time. Removing them won't save you time; you just spent time looking for some of the bits, and your diff is nowhere near complete. There will be bits everywhere all the way through the tree all the way to the man pages, which you'll end up leaving for others, so others will be compelled to clean that up, and not do something else. That's a real time loss. I'm writing this mail, which is a time loss. Secondly, those drivers are not standing in the way of any changes in the tree. We are not changing any API they depend on. There are too many of these drivers to even consider changing an API that all of these drivers depend on, and you will not attritition them down to a manageable subset in any case. Third, we don't know if someone is running them or not. dmesglog is not authoritative.
Re: goodbye to some isa devices
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 of something else in the tree. There is no point in half-disconnecting something from the tree; it is just leaving a mess for someone else down the line.
Re: goodbye to some isa devices
Todd T. Fries todd at fries.net writes: I'd wager a bet that I could make my sea(4) scsi adapter work more reliably than any variant of usb wi(4), so perhaps we should disable usb wi(4) to save you time building instead? My 2 cents. Nuke tcic0 *and* pcic*: * searching archives bring dmesgs from 3.x/4.x era, * how big chances are to run 5.x on laptops with these PCMCIA controllers? 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? Cheers, Alexey
Re: goodbye to some isa devices
Alexey E. Suslikov alexey.suslikov at gmail.com writes: Not sure about ancient 3Com's, but they are Ethernet at least, in contract to Token-Ring device like tr*. Do we support Token-Ring? Joystick driver?
Re: goodbye to some isa devices
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 should disable usb wi(4) to save you time building instead? Actually, I deliberately excluded drivers with multiple bus attachments because the attachment shim is usually pretty small. Unless we're disabling wi at pcmcia too (and I don't think we are), there's not much point in removing just the usb part. Just for the record.
Re: goodbye to some isa devices
On Mar 26, 2013, at 10:06 PM, Creamy cre...@nocrater.com wrote: Looking to the future, when are we going to drop 486 support, anyway? Now, that's a more interesting thing ask. How much of the hardware survives now, anyway? I mean at least the old Vaxen were, (and are), maintainable. 486 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. From personal experience, the oldest things I've used *recently* was a Pentium Pro a few years back for providing Internet connectivity. That was when we barely had a single Mbit/s per line here in Germany. To be honest, it was about 8 years ago. I know a case study means nothing, so let me try another route. You would only need to upgrade to the latest and greatest release if one of the following is true: (1) Your system is connected to the Internet and thus requires frequent security updates. (2) You want to run services that are bleeding edge like OpenSMTPD out of the box. (3) You are crazy. But seriously, if there is no networking, there is no need to run a recent release. And you will be able to run 5.3 in any case. And why would you use networking anyway with such small throughput, the likelihood of your tiny IBM disk (a, those were the days!) failing on you any second now. All you've got there is a ticking time bomb. Nobody in their right mind would have such a system as mission critical infrastructure. :)
Re: goodbye to some isa devices
On Mar 26, 2013, at 11:11 PM, Creamy cre...@nocrater.com wrote: On Tue, Mar 26, 2013 at 10:50:40PM +0400, Franco Fichtner wrote: Nobody in their right mind would have such a system as mission critical infrastructure. :) What, like using a Honeywell 316 as a nuclear power station reactor 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. Point taken; you are right. Scenario (3) is the most likely.
