[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 5834 bytes --]

On Mon, Nov 4, 2024 at 8:14 PM Larry McVoy <lm@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_bmap.c

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

[-- Attachment #2: Type: text/html, Size: 8443 bytes --]