[TUHS] Re: DG UNIX History

[Warner Losh <imp@bsdimp.com>]

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

On Mon, Nov 14, 2022 at 11:03 PM Theodore Ts'o <tytso@mit.edu> wrote:

> On Mon, Nov 14, 2022 at 04:54:54PM -0700, Warner Losh wrote:
> > > The interesting thing again, is that while they while all of these
> > > implementations seem to have been technologically 'better' - only Mach
> > > lived on from the original developers.  And in the case of Mach, by the
> > > time it was mainstream (macOS) the original implementation had been
> > > replaced a few times - so while the concepts are there, I don't think
> much
> > > of the Original CMU code is left in XNU/Darwin [or for that matter in
> the
> > > OSF flavors -- Tru64 rewrote it but it died and the OSF/RI kernel never
> > > went anywhere either].
> >
> > Both FreeBSD and NetBSD re-wrote the vm layer. FreeBSD incrementally, and
> > NetBSD with a new uvm. At least for FreeBSD, this is when the buffer
> cache
> > was fully (or more fully?) unified because it wasn't quite complete in
> > 4.4BSD as shipped IIRC (or maybe it was that it was really buggy, it's
> been
> > so long ago now that I've forgotten).
>
> FWIW, Linux also has a (mostly) unified page cache.  Which is to say,
> for all of the major file systems, there is only a single unified page
> cache for file data.
>
> There are some legacy file systems in Linux (e.g., befs, qnx4, qnx6,
> minix, vfat, etc.) that still use the buffer cache, but the buffer
> cache is implemented in terms of the page cache infrastructure, and
> that's mainly because no one has really bothered to update those file
> systems to use the unified page cache.  After all, you're using vfat
> to read and write for super-slow USB thumb drive, who cares if data is
> getting copied from the USB thumb drive, to the buffer cache, and then
> to the page cache?  :-)
>
> > > As I said, the lesson to TUHS -- as much as I'm a techie and I am
> > > interested in the 'proper' way of doing things ... "good enough" is
> often
> > > what rules.
> >
> > Good enough, and a little more polish to make it even better :)
>
> Good enough, and backwards compatibility, sure.  But for the file
> systems where performance is an issue, having a unified page is the
> only way to go.  :-)
>
> > > It's too bad none of the good memory implementations made it into
> > > >>systems<< that lasted.ᐧ
>
> At least in my book, it's not the implementations, but the ideas that
> matter.  And sometimes implementations are constrained by hardware
> limitations (example: clists), and for less contrained hardware,
> sometimes you're better re-evaluating whether the ideas in use, and if
> that means that you need to reimplement the ideas that still make
> sense, there's nothing wrong with that.
>
>                                         - Ted
>
> P.S.  I remember back in the day when I was engaging in a friendly
> competition with a FreeBSD hacker on improving the serial driver for
> the 8250 chip (with no FIFO's!), and I shared with him my idea of
> using a pair of ring buffers that would get flipped back and forth
> between the interrupt handler and the tty "bottom-half" (read:
> software interrupt) handler, and I was told that clists were handed
> down from Olympus by the AT&T/Unix Gods and he could never get that
> kind of change into the FreeBSD tty layer.  Of course, I was free to
> make all of the radical changes to Linux's tty layer --- and I did,
> all in the name of the number of 115kbaud connections that could be
> handled on a single 40 MHz 386 processor...
>

Thankfully, clists have been gone forever from the FreeBSD tty layer (since
FreeBSD 2 or 3 if memory serves). The soft interrupt stuff had to wait to
be replaced until the SMPng efforts to make FreeBSD scale on multicore.
Some cruft remains in the tty layer, to be sure, but it's somewhat better
than before.

Bruce was quite active in FreeBSD and did drive much change in our
thinking, though mostly through getting others to rewrite it in the right
way after the main proponents of that dogma left the project and we could
grow beyond that past. It was a mistake in the earliest days to think
anything from AT&T was sacrosanct and the project is much healthier for
it... We'd never been able to scale with the old AT&T inherited design on
many many things.

Warner

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