On 5/27/26 14:00, Jason Thorpe wrote:
I am on a quest to properly unify the m68k user-land, which means addressing
some long-standing ABI differences in some of the darker corners ofthe system.
One particularly dark corner is BSD disklabel handling, which, from where I
sit, is a giant toxic dumpster fire raging in the middleof the Bog of Eternal
Stench. But I don’t have time for that rant this morning.
Hehe. This will be fun...
So, let’s focus on DEC STD 144, a.k.a. bad144, a.k.a. dkbad. It’s a 1970s-era
bad sector remapping scheme that was already mostly obsolete by the mid-80s
(ever since SCSI drives were able to maintain their own bad sector remapping
information). It is totally and completely useless on any drive made since the
1990s. And yet, its tendrils infest many a NetBSD port’s BSD disklabel
handling because, as far as I can tell, cargo-cultism.
I was always both surprised and annoyed by bad144 in NetBSD.
More on that below...
I figure there are a handful of legit use cases for bad144 in NetBSD still:
- The vax port, obviously, but only with the really old drives. (VAX peeps
please help me out here - is bad144 useful drives behind an MSCP-compliant
controller?)
No. Any drive using MSCP do not use bad144. MSCP, just like SCSI,
guarantees an error free disk. Any bad block mapping happens in the
controller.
*However*, other drives do use DEC STD 144. So that means RL, RM and RP
drives (which are still supported on the VAX side). But with that said,
bad144 have never (as far as I know) been supported/allowed on VAXen.
Which annoys/perplex me to no end. The only platform that actually have
disks using DEC STD 144 is one where bad144 is not built. How did that
come about???
From the Makefile in /usr/src/usr.sbin/bad144:
.if ${MACHINE_ARCH} == "alpha" || ${MACHINE_ARCH} == "i386"
PROG= bad144
.endif
So, only built for i386 and Alpha. :-(
I guess technically some DEC Mips based machines could have RL drives,
so apart from VAX, possibly Mips would be the only really valid user.
- hp300 port maybe (for HP-IB drives).
Do those really have a bad block list on the last track done the same
way as DEC STD 144 specifies?
- sun3 / sun4 (Xylogics controllers and SMD drives)
Same question.
- i386 (ESDI, ST506, other ancient drive technologies that can plug into ISA or
MCA)
Same question.
What I would like to propose is that bad144 be completely decoupled from
“disklabel” and refactored out as set of library routines (slash module) that
drivers can use. But, most importantly, get it out of the main “BSD disklabel”
code path.
And so, let’s discuss.
bad144 should be reading the bad block list from the last track of a
media, and I guess it then populates a list of bad blocks in the disk
label, right?
So is there really a couplinng in here? Or isn't just bad144 one way of
populating that bad block list in the disklabel. But the list as such
needs to be somewhere where the disk driver can access it and handle it
accordingly, no?
And that is independent of bad144 as such.
But I might have missed something.
Johnny
