goodbye to some isa devices

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

goodbye to some isa devices

Ted Unangst-6
These isa devs are already disabled and not particularly popular among
our users.  affected: tcic, sea, wds, eg, el

Index: arch/i386/conf/GENERIC
===================================================================
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.744
diff -u -p -r1.744 GENERIC
--- arch/i386/conf/GENERIC 15 Mar 2013 09:10:52 -0000 1.744
+++ arch/i386/conf/GENERIC 26 Mar 2013 08:20:40 -0000
@@ -188,7 +188,6 @@ nvt* at iic? # Novoton W83795G
 pcic0 at isa? port 0x3e0 iomem 0xd0000 iosiz 0x10000
 pcic1 at isa? port 0x3e2 iomem 0xe0000 iosiz 0x4000
 pcic2 at isa? port 0x3e4 iomem 0xe0000 iosiz 0x4000
-tcic0 at isa? disable port 0x240 iomem 0xd0000 iosiz 0x10000
 
 # 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
-#wds1 at 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 -0000 1.194
+++ arch/i386/conf/RAMDISK_CD 26 Mar 2013 08:19:13 -0000
@@ -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
-#wds1 at isa? port 0x358 irq 11 drq 5
+
 softraid0 at 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 -0000 1.211
+++ arch/i386/conf/files.i386 26 Mar 2013 08:19:33 -0000
@@ -362,12 +362,6 @@ file dev/isa/i82365_isapnp.c pcic_isapnp
 # Code common to ISA and ISAPnP attachments
 file dev/isa/i82365_isasubr.c pcic_isa | pcic_isapnp | pcic_pci
 
-# Databook TCIC/2 pcmcia/isa bridge
-device tcic: pcmciabus
-file dev/ic/tcic2.c tcic
-attach tcic at isa with tcic_isa
-file dev/isa/tcic2_isa.c tcic_isa
-
 #
 # Machine-independent PCMCIA drivers
 #
Index: dev/isa/files.isa
===================================================================
RCS file: /cvs/src/sys/dev/isa/files.isa,v
retrieving revision 1.111
diff -u -p -r1.111 files.isa
--- dev/isa/files.isa 29 Jun 2011 17:48:22 -0000 1.111
+++ dev/isa/files.isa 26 Mar 2013 08:15:07 -0000
@@ -99,21 +99,11 @@ device aha: scsi, isa_dma
 attach aha at isa with aha_isa
 file dev/isa/aha.c aha needs-flag
 
-# Seagate ST0[12] ICs
-device sea: scsi
-attach sea at isa
-file dev/isa/seagate.c sea
-
 # UltraStor UHA-[13]4f boards
 # device declaration in sys/conf/files
 attach uha at isa with uha_isa: isa_dma
 file dev/isa/uha_isa.c uha_isa
 
-# Western Digital WD7000 and Future Domain TMC-7000 boards
-device wds: scsi, isa_dma
-attach wds at isa
-file dev/isa/wds.c wds
-
 # OPTi 82C929 chipset setup code
 define opti
 file dev/isa/opti.c opti
@@ -154,16 +144,6 @@ file dev/isa/elink.c elink
 device ec: ether, ifnet, dp8390nic, ifmedia
 attach ec at isa
 file dev/isa/if_ec.c ec
-
-# 3Com 3C505
-device eg: ether, ifnet
-attach eg at isa
-file dev/isa/if_eg.c eg
-
-# 3Com 3C501
-device el: ether, ifnet
-attach el at isa
-file dev/isa/if_el.c el
 
 # 3Com 3C509 Ethernet controller
 attach ep at isa with ep_isa: elink


Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Mark Kettenis
> Date: Tue, 26 Mar 2013 05:20:27 -0400
> From: Ted Unangst <[hidden email]>
>
> 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/GENERIC 15 Mar 2013 09:10:52 -0000 1.744
> +++ arch/i386/conf/GENERIC 26 Mar 2013 08:20:40 -0000
> @@ -188,7 +188,6 @@ nvt* at iic? # Novoton W83795G
>  pcic0 at isa? port 0x3e0 iomem 0xd0000 iosiz 0x10000
>  pcic1 at isa? port 0x3e2 iomem 0xe0000 iosiz 0x4000
>  pcic2 at isa? port 0x3e4 iomem 0xe0000 iosiz 0x4000
> -tcic0 at isa? disable port 0x240 iomem 0xd0000 iosiz 0x10000
>  
>  # 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
> -#wds1 at 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 -0000 1.194
> +++ arch/i386/conf/RAMDISK_CD 26 Mar 2013 08:19:13 -0000
> @@ -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
> -#wds1 at isa? port 0x358 irq 11 drq 5
> +
>  softraid0 at 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 -0000 1.211
> +++ arch/i386/conf/files.i386 26 Mar 2013 08:19:33 -0000
> @@ -362,12 +362,6 @@ file dev/isa/i82365_isapnp.c pcic_isapnp
>  # Code common to ISA and ISAPnP attachments
>  file dev/isa/i82365_isasubr.c pcic_isa | pcic_isapnp | pcic_pci
>  
> -# Databook TCIC/2 pcmcia/isa bridge
> -device tcic: pcmciabus
> -file dev/ic/tcic2.c tcic
> -attach tcic at isa with tcic_isa
> -file dev/isa/tcic2_isa.c tcic_isa
> -
>  #
>  # Machine-independent PCMCIA drivers
>  #
> Index: dev/isa/files.isa
> ===================================================================
> RCS file: /cvs/src/sys/dev/isa/files.isa,v
> retrieving revision 1.111
> diff -u -p -r1.111 files.isa
> --- dev/isa/files.isa 29 Jun 2011 17:48:22 -0000 1.111
> +++ dev/isa/files.isa 26 Mar 2013 08:15:07 -0000
> @@ -99,21 +99,11 @@ device aha: scsi, isa_dma
>  attach aha at isa with aha_isa
>  file dev/isa/aha.c aha needs-flag
>  
> -# Seagate ST0[12] ICs
> -device sea: scsi
> -attach sea at isa
> -file dev/isa/seagate.c sea
> -
>  # UltraStor UHA-[13]4f boards
>  # device declaration in sys/conf/files
>  attach uha at isa with uha_isa: isa_dma
>  file dev/isa/uha_isa.c uha_isa
>  
> -# Western Digital WD7000 and Future Domain TMC-7000 boards
> -device wds: scsi, isa_dma
> -attach wds at isa
> -file dev/isa/wds.c wds
> -
>  # OPTi 82C929 chipset setup code
>  define opti
>  file dev/isa/opti.c opti
> @@ -154,16 +144,6 @@ file dev/isa/elink.c elink
>  device ec: ether, ifnet, dp8390nic, ifmedia
>  attach ec at isa
>  file dev/isa/if_ec.c ec
> -
> -# 3Com 3C505
> -device eg: ether, ifnet
> -attach eg at isa
> -file dev/isa/if_eg.c eg
> -
> -# 3Com 3C501
> -device el: ether, ifnet
> -attach el at isa
> -file dev/isa/if_el.c el
>  
>  # 3Com 3C509 Ethernet controller
>  attach ep at isa with ep_isa: elink
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Ted Unangst-6
In reply to this post by Ted Unangst-6
On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:

>> Date: Tue, 26 Mar 2013 05:20:27 -0400
>> From: Ted Unangst <[hidden email]>
>>
>> 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.

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Creamy
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

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Loganaden Velvindron-2
In reply to this post by Ted Unangst-6
On Tue, Mar 26, 2013 at 5:09 PM, Ted Unangst <[hidden email]> wrote:

> On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
>>> Date: Tue, 26 Mar 2013 05:20:27 -0400
>>> From: Ted Unangst <[hidden email]>
>>>
>>> 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 !

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Kenneth R Westerback
In reply to this post by Ted Unangst-6
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 <[hidden email]>
> >>
> >> 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

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Ted Unangst-6
In reply to this post by Ted Unangst-6
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.

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Mark Kettenis
In reply to this post by Ted Unangst-6
> Date: Tue, 26 Mar 2013 09:09:14 -0400
> From: Ted Unangst <[hidden email]>
>
> On Tue, Mar 26, 2013 at 11:13, Mark Kettenis wrote:
> >> Date: Tue, 26 Mar 2013 05:20:27 -0400
> >> From: Ted Unangst <[hidden email]>
> >>
> >> 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.

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Todd T. Fries-2
In reply to this post by Ted Unangst-6
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 <[hidden email]>
| >>
| >> 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 .. [hidden email]

 ____________________________________________
|                                            \  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:[hidden email]
| "..in support of free software solutions." \  sip:[hidden email]
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Miod Vallat
In reply to this post by Ted Unangst-6
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Franco Fichtner-2
In reply to this post by Creamy
On Mar 26, 2013, at 6:26 PM, Creamy <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Theo de Raadt
In reply to this post by Ted Unangst-6
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.

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Theo de Raadt
In reply to this post by Ted Unangst-6
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Alexey Suslikov
In reply to this post by Todd T. Fries-2
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

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Alexey Suslikov
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?

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Creamy
In reply to this post by Franco Fichtner-2
On Tue, Mar 26, 2013 at 09:00:39PM +0400, Franco Fichtner wrote:

> On Mar 26, 2013, at 6:26 PM, Creamy <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Ted Unangst-6
In reply to this post by Ted Unangst-6

> 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.

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Franco Fichtner-2
In reply to this post by Creamy
On Mar 26, 2013, at 10:06 PM, Creamy <[hidden email]> 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 (awwww, 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. :)

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Creamy
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

Reply | Threaded
Open this post in threaded view
|

Re: goodbye to some isa devices

Franco Fichtner-2
On Mar 26, 2013, at 11:11 PM, Creamy <[hidden email]> 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.

123