5 Nov
2024
5 Nov
'24
11 a.m.
On Mon, Nov 4, 2024 at 8:14 PM Larry McVoy <lm(a)mcvoy.com> wrote:
The bmap implementations I saw were bit for bit
identical, same code, same
variables, same style, same indentation. I'm 100% sure they were not
independent. 100% sure.
They are different in 4.3BSD. They are different in 4.2BSD (but less
different). The underlying filesystems are different on disk, so they
routines have to be different.
You may be 100% sure, but it's not this specific routine.
I've traced that code through all the Bell Labs
stuff to BSD. The idea
that BSD redid this code the same way, in my mind, is a bridge too far.
bmap() knows about how stuff is laid out on disk, knows about how stuff
works in the inode (think indirect blocks and double indirect blocks),
there is _no_ _way_ BSD wrote the same code independently. No f-ing
way. They just took it.
You may have found a routine like that, but it's not the bmap routine. It
evolved
from when they started with 32V, true and was copied to ufs_bmap.c 4.2BSD
and
altered to work with the new filesystem layout.
For 4BSD and 4.1BSD it's still in subr.c, where it is in 32V and V7. But
even there,
it's writing directories synchronously but other files async. 32V writes
everything
asynchronously. And a few other diffs if you study.
But the routine bmap was copied to ufs_bmap in 4.2BSD and changed.
It was changed further in 4.3BSD, and further still in 4.4BSD. The code
for this is clear, but in the TUHS repo and on Kirk's disk.
https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/subr.c
https://www.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/src/sys/sys/subr.c
https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/sys/ufs_bmap.c
https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/sys/sys/ufs_bmap.c
and net/2 had ufs_bmap.c. Berkeley agreed to stop distributing it as
it was there, likewise with 4.4BSD.
4.4BSD-Lite has a completely rewritten ufs_bmap.c (I'd checked 4.4bsd-alpha
before). It's very very different. There's an AT&T copyright on the file,
but bmap
is completely different (and it calls routines that are completely
different). You
can see if from the online 4.4-BSDlite2 artifacts (the 4.4 directory from
kirk's
collection also has 4.4-Lite, I believe, and the file is almost the same).
https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/sys/ufs/ufs/ufs_…
has the online copy if people want to check it out.
I know we all want to think all the Bell Labs code is
free or has been
reimplemented and it's all good, we're clean. We're not.
The historical artifacts we have don't show that. Plus, the ancient unix
license gives the right to 32V and 32V derived systems (which all the BSDs
are),
so even if what you said is true, there's a good foundation (but what you
say
is not true, bmap is not 100% identical between 32V and even 4BSD, let alone
4.4BSD-lite, where it's completely re-written.
It doesn't matter at this point but it matters to
me that we are honest
about how we got here.
We got here in large part due AT&T and Berkeley working out their
differences,
Berkeley rewriting some code and AT&T signing off on 4.4BSD-lite and
Berkeley signing off on System V (since AT&T had also copied from Berkeley
without credit).
Now, maybe there was some other routine, or maybe it was Net2 that you found
it in (and it was fixed), but 4.4BSD-lite is clean in this respect.
Warner
On Mon, Nov 04, 2024 at 05:32:19PM -0800, ron minnich
wrote:
I had people relate to me, at least once, cases
of utterly independent
implementations of a function that were byte for byte the same, as found
in
one court case a friend of mine (now deceased)
got pulled into. He had to
prove he'd written his code from scratch. But these were pretty simple
functions. I don't know if bmap qualifies ...
How could this happen? I don't know, but the court case that long
predated
SCO. The only conclusion I can reach
is that when enough techniques, ideas, mailling lists, discussions, and
documents become part of a shared culture, the code which
people create might be the same. A weird parallel evolution of code.
On Mon, Nov 4, 2024 at 5:09???PM Larry McVoy <lm(a)mcvoy.com> wrote:
> The thing I never got a reasonable answer to was I found code in BSD
that
> was identical to code going back to at least
V7. Find bmap() in the
UFS
> code and then find the same in V7. I might
be wrong about V7, might be
> 32V, might be V6. I don't think it matters, it's the same in all of
them.
>
> bmap() is the code that maps a logical block to a phsyical block,
> I'm quite familiar with it because I rewrote it to bmap_write() and
> bmap_read() as part of making UFS do extents:
>
> http://mcvoy.com/lm/papers/SunOS.ufs_clustering.pdf
>
> When all the lawsuits were going on, since I knew that code really
well,
> I went off and looked and the BSD code at
that time had bit for bit
> identical bmap() implementations.
>
> I never understood why BSD could claim they rewrote everything when
they
> clearly had not rewritten that.
>
> I've raised this question before and I just went and looked, bmap() has
> changed. I'm pretty sure I have Kirk's BSD source releases, if I do,
> I'm 100% sure I can back up what I'm saying. Not sure I care enough to
> do so, it's all water under the bridge at this point.
> --
> ---
> Larry McVoy Retired to fishing
> http://www.mcvoy.com/lm/boat
>
--
---
Larry McVoy Retired to fishing
http://www.mcvoy.com/lm/boat