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