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

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sat, May 30, 2026 at 04:12:17PM +0200, Anders Magnusson wrote:
> Den 2026-05-30 kl. 15:33, skrev Jason Thorpe:
> > 
> > > On May 28, 2026, at 6:17???AM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> > > 
> > > 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???).
> > 
> > Well, in any case, here???s the diff that re-factors bad144 stuff (mostly) into ???one??? place.
> > 
> >      https://www.netbsd.org/~thorpej/bad144-refactor-diffs.txt
> > 
> Good work!  This means it would be quite simple to add bad144 to the vax
> drives missing it as well :-)
> 
> Just for curiosity; why did the Sun SMD drives use bad144?  Was it something
> that Sun did or was it added by us? (since it's a DEC thingie).

The underlying hardware's often the same (CDC made the guts of plenty of
DEC drives), SMD drives internally have no facility for sparing out sectors,
and I wonder whether Sun did in fact do it.  However, I just Googled around
for SunOS 3 source code and I see no evidence of a bad144 utility, though
I did not dig through the kernel looking for driver support.

Since the bad144 *program* showed up in the BSD source tree around the time
SunOS originally diverged (but I believe kernel drivers had support first,
since formatting utilities were what more usually wrote the table for most
drive types) I also had a look at SunOS 4.  Not there either.

-- 
Thor Lancelot Simon	                                     tls%panix.com@localhost
  "The liberties...lose much of their value whenever those who have greater
   private means are permitted to use their advantages to control the course
   of public debate."					-John Rawls