<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 5, 2024 at 10:55 AM Noel Chiappa <<a href="mailto:jnc@mercury.lcs.mit.edu">jnc@mercury.lcs.mit.edu</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">    > From: Warner Losh<br>
<br>
    >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote:<br>
<br>
    >> The bmap implementations I saw were bit for bit identical, same code,<br>
    >> same variables, same style, same indentation. I'm 100% sure they were<br>
    >> not independent.<br>
<br>
    > They are different in 4.3BSD. They are different in 4.2BSD (but less<br>
    > different). The underlying filesystems are different on disk, so they<br>
    > routines have to be different.<br>
<br>
That last sentence points out something important that people need to remember<br>
in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD<br>
switched to the BSD Fast File System, so I very much doubt that the low-level<br>
(i.e. logical file block to disk block) file system code in anything after<br>
4.1A looks much like the AT+T low-level file system code. (I have no idea how<br>
the BSD code compares to the Linux file system code, but that's between the<br>
Linux people, and Berkeley.)<br></blockquote><div><br></div><div>Yes. The original unix code was copied and redone somewhat. It was still likely</div><div>a derivative work (which is why AT&T forced Berkeley to redo it for 4.4-lite), but</div><div>it was like 25% the same, 25% similar but functionally identical and 50% new for</div><div>UFS, but filesystem layout is file system layout and some similarities persisted.</div><div>3bsd added dtofsb() calls. 4bsd added code to make accessing the indirect blocks</div><div>more reliable and made writing directories more reliable.  4.1 was identical to 4bsd.</div><div>4.2 changed a lot. the 32V bmap was 112 lines long, while 4.2 was 196 lines with</div><div>the following diffstat:</div><div> 1 file changed, 141 insertions(+), 57 deletions(-)<br></div><div>So by this measure, over half of the new function was new (though most of the</div><div>comments were still the same). It did have the same structure, but structure isn't</div><div>necessarily copyrightable since filesystem layout code will be similar between</div><div>filesystems that are write-in-place. Looking at the diff, there's one stretch of 15</div><div>lines that are identical, but otherwise there's changes (mostly additions) every</div><div>few lines. A substantial re-write. These days, most open source authors would</div><div>replace the copyright statement with their own for such an extensive rewrite</div><div>since the diff was over 2x the size of the original file (another very imperfect</div><div>measure). Though the comments remaining identical is troublesome because</div><div>they are the parts of the code that are the most creative and subject to the</div><div>most freedom while the for loops and such are largely dictated by the problem</div><div>or C language and customary style.</div><div><br></div><div>Between 4.2 and 4.3, the changes were around the edges of this function</div><div>though not in this function (I was remiss in not chasing down the bare diff</div><div>I did last night). By net.2 it was re-written again, moving most of the function</div><div>of bmap elsewhere, so that almost nothing remained from the original 32V</div><div>in the original bmap function (though a quick grep shows that parts did move</div><div>elsewhere). In net.2 it's back down to 75 lines. shorter even than in 32V (but</div><div>it's a bit deceptive since the code was elsewhere, though also largely reworked).</div><div>diff reports only lines '{', '}', '/*', '*/' and a few simple assignments</div><div>(bap = bp->b_un.b_daddr;) and function calls (brelse(bp)) being the same and</div><div>all the comments different / gone from this function. Though a fair number of</div><div>the diffs were due to changes in the "buffer cache" interface, some formatting</div><div>changes and some substitution of #defines (like NIADDR) for bare constants (3</div><div>in this case). These changes were also due to the role of bmap being reduced</div><div>and things like balloc being used to handle the details a fair bit differently. And</div><div>bits of balloc do resemble bits of the original bmap, but again the structure</div><div>had changed somewhat.</div><div><br></div><div>The numbers for my diffs and such are based on Krik's disks, but can also</div><div>be tested by looking at the links I posted earlier or downloading and extracting</div><div>the sources from the TUHS archive.</div><div><br></div><div>The bmap() function I've extracted from different versions:</div><div><br></div><div><a href="https://people.freebsd.org/~imp/pmap/pmap.32v">https://people.freebsd.org/~imp/pmap/pmap.32v</a></div><div><div><a href="https://people.freebsd.org/~imp/pmap/pmap.4.2">https://people.freebsd.org/~imp/pmap/pmap.4.2</a></div></div><div><div><a href="https://people.freebsd.org/~imp/pmap/pmap.4.3">https://people.freebsd.org/~imp/pmap/pmap.4.3</a></div></div><div><div><a href="https://people.freebsd.org/~imp/pmap/pmap.net.2">https://people.freebsd.org/~imp/pmap/pmap.net.2</a></div></div><div><br></div><div>Warner<br></div><div><br></div></div></div>