Re: bad144 - how useful still? Because it's annoyingly ubiquitous.

[Jason Thorpe <thorpej%me.com@localhost>]

> On May 28, 2026, at 6:01 AM, Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> 
> It's concievable the Xylogics controllers and their drivers would work
> (if the Connector Conspiracy did not intervene) not just with the CDC 97xx
> drives that were commonly used on larger minicomputers (on VAXen, usually
> via Emulex controllers on Massbus) but with their OEM variants, including
> several from DEC and, I think, some from other CPU manufacturers too.
> 
> These have removable packs and are not an implausible
> target for historical data-recovery.  I actually think that's an important
> use we should support.  However, I also think _booting_ from such a drive
> actually is one of the higher-risk practices if one is concerned about
> its data forever descending into the memory hole, and I don't think we
> need direct support in the device drivers for any reason except to boot.

I mean, if that’s where the OS is installed and you don’t happen to have a SCSI3 board, that’s what you’re booting from.  (Ok, sure, you can net-boot, but *really*?)

> This pushes me further towards the conclusion that if any reorganization
> of how the kernel handles bad144 is in order, a pseudodevice would make
> the most sense.

I think everyone is over-thinking this, here.  What I intend to do is quite minimally-invasive and leaves the logic in the individual drivers that consume it essentially intact (a flag-in-the-disklabel check will be replaced by a pointer-in-the-softc check for “maybe we have to re-map a sector”).

-- thorpej