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