The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re: DG UNIX History
@ 2022-11-14 22:11 Paul Ruizendaal
  2022-11-14 22:31 ` Clem Cole
  0 siblings, 1 reply; 23+ messages in thread
From: Paul Ruizendaal @ 2022-11-14 22:11 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

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

> Date: Sat, 12 Nov 2022 17:56:24 -0800
> From: Larry McVoy <lm@mcvoy.com>
> Subject: [TUHS] Re: DG UNIX History
> 
> It sounds like they could have supported mmap() easily.  I'd love to see
> this kernel, it sounds to me like it was SunOS with nicely done SMP 
> support.  The guy that said he'd never seen anything like it before or
> since, just makes me want to see it more.

> I know someone who was friends with one of the kernel guys, haven't talked
> to her in years but I'll see if I can find anything.

Following on from the exchange on TUHS about DG-UX, it would seem to me that the (Unix) unified cache was invented at least three times for Unix:
- John Reiser at AT&T
- At Sun
- At DG

As to the latter I could find two leads that might help you finding out more. It would seem that this unique Unix is specifically DG-UX version 4:

https://web.archive.org/web/20070930212358/http://www.accessmylibrary.com/coms2/summary_0286-9202012_ITM

and

Michael H. Kelly and Andrew R. Huber, "Engineering a (Multiprocessor) Unix Kernel", Proceedings of the Autumn 1989 EUUG Conference, European Unix Systems User Group, Vienna, Austria, 1989, pp. 7- 19.

The unified cache isn’t mentioned, but it would seem that the multiprocessor redesign might have included it. Maybe the author names are helpful. I could not find the paper online, but there was a web page suggesting that a paper copy still exists in a (university?) library in Sweden.

=====

Publication: DG Review 

Publication Date: 01-NOV-88
Author: Huber, Andrew R. 


DG-UX 4.00: DG's redesigned kernel lays the foundation for future UNIX systems. (includes related article on DG-UX 4.00's file system and an excerpt from Judith S. Hurwitz's 'Data General's UNIX strategy: an evaluation' report)

COPYRIGHT 1988 New Media Publications 

DG/UX 4.00 

Revision 4.00 of Data General's native UNIX operating system siginificantly enhances the product and adds unique capabilities not found in other UNIX implementations. This article reviews the goals of DG/UX 4.00 and discusses some of its features. 

When DG released DG/UX 1.00 in March, 1985, it was based on AT&T's System V Release 2 and incorporated the Berkeley UNIX file system and networking. 

As DG/UX grew, it continued to incorporate functions of the major standard UNIX systems, as illustrated in the following timeline: 

* DG/UX 1.00 March, 1985 Based on System V Release 2 and Berkely 4.1. 

      Included Berkely 4.2 file system and TCP/IP (LAN). 

* DG/UX 2.00, September, 1985 Added Berkeley 4.2 system calls. 

* DG/UX 3.00, April 1986 Added support for new DG hardware. 

* DG/UX 3.10 March, 1987 Added Sun Microsystem's Network File System.sup.(R) Added X Windows. 

* DG/UX 4.00, August, 1988 Re-designed and re-implemented kernel and file system.




[-- Attachment #2.1: Type: text/html, Size: 4524 bytes --]

[-- Attachment #2.2: separator.gif --]
[-- Type: image/gif, Size: 43 bytes --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-14 22:11 [TUHS] Re: DG UNIX History Paul Ruizendaal
@ 2022-11-14 22:31 ` Clem Cole
  2022-11-14 23:54   ` Warner Losh
  2022-11-15  1:21   ` Stuff Received
  0 siblings, 2 replies; 23+ messages in thread
From: Clem Cole @ 2022-11-14 22:31 UTC (permalink / raw)
  To: Paul Ruizendaal; +Cc: The Eunuchs Hysterical Society

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

On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal <pnr@planet.nl> wrote:

> Following on from the exchange on TUHS about DG-UX, it would seem to me
> that the (Unix) unified cache was invented at least three times for Unix:
>
Not to quibble too much, but s/cache/memory/  I think is a fairer way of
saying that.


> - John Reiser at AT&T
> - At Sun
> - At DG
>
- At CMU (Mach)

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].

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.

It's too bad none of the good memory implementations made it into
>>systems<< that lasted.

Clem
ᐧ

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-14 22:31 ` Clem Cole
@ 2022-11-14 23:54   ` Warner Losh
  2022-11-15  6:03     ` Theodore Ts'o
  2022-11-15  1:21   ` Stuff Received
  1 sibling, 1 reply; 23+ messages in thread
From: Warner Losh @ 2022-11-14 23:54 UTC (permalink / raw)
  To: Clem Cole; +Cc: Paul Ruizendaal, The Eunuchs Hysterical Society

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

On Mon, Nov 14, 2022 at 3:33 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal <pnr@planet.nl> wrote:
>
>> Following on from the exchange on TUHS about DG-UX, it would seem to me
>> that the (Unix) unified cache was invented at least three times for Unix:
>>
> Not to quibble too much, but s/cache/memory/  I think is a fairer way of
> saying that.
>
>
>> - John Reiser at AT&T
>> - At Sun
>> - At DG
>>
> - At CMU (Mach)
>
> 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). Neither are, imho, as good as Sun's
in this respect, but both have been better tuned to scale better than
SunOS. IIRC from OS/MP days, the buffer cache lock contention started to
get bad around 8 or so CPUs (to be fair: SunOS was never MP, these were
Solbourne's locking modifications that weren't super-fine grained).


> 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 :)


> It's too bad none of the good memory implementations made it into
> >>systems<< that lasted.ᐧ
>

Yea...

Warner

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-14 22:31 ` Clem Cole
  2022-11-14 23:54   ` Warner Losh
@ 2022-11-15  1:21   ` Stuff Received
  1 sibling, 0 replies; 23+ messages in thread
From: Stuff Received @ 2022-11-15  1:21 UTC (permalink / raw)
  To: tuhs

On 2022-11-14 17:31, Clem Cole wrote:
> On Mon, Nov 14, 2022 at 5:12 PM Paul Ruizendaal <pnr@planet.nl> wrote:
>
>     Following on from the exchange on TUHS about DG-UX, it would seem
>     to me that the (Unix) unified cache was invented at least three
>     times for Unix:
>
> Not to quibble too much, but s/cache/memory/  I think is a fairer way 
> of saying that.
>
>     - John Reiser at AT&T
>     - At Sun
>     - At DG
>
> - At CMU (Mach)
>
> 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].

The CMU copyrights are still there 
(https://github.com/apple-opensource/xnu/tree/master/osfmk/mach). 
Perhaps someone far more knowledgeable than me could spelunk.

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

Indeed.

>
> It's too bad none of the good memory implementations made it into 
> >>systems<< that lasted.
>
> Clem
> ᐧ


^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-14 23:54   ` Warner Losh
@ 2022-11-15  6:03     ` Theodore Ts'o
  2022-11-15 15:11       ` Larry McVoy
  2022-11-15 17:47       ` Warner Losh
  0 siblings, 2 replies; 23+ messages in thread
From: Theodore Ts'o @ 2022-11-15  6:03 UTC (permalink / raw)
  To: Warner Losh; +Cc: Paul Ruizendaal, The Eunuchs Hysterical Society

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-15  6:03     ` Theodore Ts'o
@ 2022-11-15 15:11       ` Larry McVoy
  2022-11-15 15:48         ` Bakul Shah
  2022-11-15 17:47       ` Warner Losh
  1 sibling, 1 reply; 23+ messages in thread
From: Larry McVoy @ 2022-11-15 15:11 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: Paul Ruizendaal, The Eunuchs Hysterical Society

On Tue, Nov 15, 2022 at 01:03:05AM -0500, Theodore Ts'o wrote:
> 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...

I remember being pleasantly surprised that Linus/Linux was open to 
that sort of change.  I get why the traditional Unix shops resisted
be wacks like that but they went too far and it prevented good work.

Linux seemed far more willing to realize that they had it wrong and
there was a better way.  That was refreshing.

Of course they got beat up for it with "Linux is stable/compatible".
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-15 15:11       ` Larry McVoy
@ 2022-11-15 15:48         ` Bakul Shah
  0 siblings, 0 replies; 23+ messages in thread
From: Bakul Shah @ 2022-11-15 15:48 UTC (permalink / raw)
  To: Larry McVoy; +Cc: Paul Ruizendaal, The Eunuchs Hysterical Society

On Nov 15, 2022, at 7:11 AM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> On Tue, Nov 15, 2022 at 01:03:05AM -0500, Theodore Ts'o wrote:
>> 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...
> 
> I remember being pleasantly surprised that Linus/Linux was open to 
> that sort of change.  I get why the traditional Unix shops resisted
> be wacks like that but they went too far and it prevented good work.
> 
> Linux seemed far more willing to realize that they had it wrong and
> there was a better way.  That was refreshing.
> 
> Of course they got beat up for it with "Linux is stable/compatible".

At Fortune Systems Dave Yost was able to achieve full-duplex 9600
baud speed on up to 5 ports in V7 Unix without changing the clist
design. This on a 5.6Mhz machine (with 4 cycle memory). The trick
was to specialize interrupt handlers for each port.


^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-15  6:03     ` Theodore Ts'o
  2022-11-15 15:11       ` Larry McVoy
@ 2022-11-15 17:47       ` Warner Losh
  1 sibling, 0 replies; 23+ messages in thread
From: Warner Losh @ 2022-11-15 17:47 UTC (permalink / raw)
  To: Theodore Ts'o; +Cc: Paul Ruizendaal, The Eunuchs Hysterical Society

[-- 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 --]

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
@ 2022-11-14 11:44 arnold
  0 siblings, 0 replies; 23+ messages in thread
From: arnold @ 2022-11-14 11:44 UTC (permalink / raw)
  To: tuhs

This is what Scott Lee, who ran the Eclipse at Georgia Tech
recalls. He has given permission for me to forward it, with
the caveat that it was long ago and that "memories are malleable".

Arnold

> Date: Mon, 14 Nov 2022 05:35:51 -0500
> Subject: Re: [TUHS] DG UNIX History
> From: scott@thelees.org
> To: arnold@skeeve.com
>
> > I'm pretty sure that DG never ported DG-UX to the Nova. There was
> > a native port to the Eclipse (32 bit).  There was also a Eunice-style
> > Unix environment that sat on top of their native OS, whatever it was
> > called.
>
> Yeh, that was an MV-10000 that we received.  As I remember it, we also got
> a copy of DG-UX, which was a port of SYS Vr2, not r3 as mentioned.  I
> think that it may have also had a directory with UCB versions of a bunch
> of the utilities ported over so you could run either SysV tools or UCB
> tools.
>
> LeBlanc was going to use it to teach ADA, so I was building some tools to
> create/maintain user accounts, but I believe that I left just before they
> were actually getting around to that.
>
> I was also playing with it on the side, when no one else was using it, to
> build a small OS on it.  I found that it followed a lot of the Nova
> behavior, so I figured out how to write code onto a tape and bootstrap it
> into the machine.  Wrote a tape driver and a console driver and was
> working on a disk driver.  Targeting putting a small OS on it.
>
> Wow... I had almost forgotten that it even existed until I saw this.
>
> Enjoy,
> Scott

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 19:36       ` Clem Cole
@ 2022-11-13  1:56         ` Larry McVoy
  0 siblings, 0 replies; 23+ messages in thread
From: Larry McVoy @ 2022-11-13  1:56 UTC (permalink / raw)
  To: Clem Cole; +Cc: tuhs

On Sat, Nov 12, 2022 at 02:36:05PM -0500, Clem Cole wrote:
> To be honest, I've forgotten many (most) of the details.  But that sounds
> about right.  As I remember it, it was like SunOS.  The key point was that
> the kernel only had one view of the memory system period, no FS
> buffer cache etc...which was a departure from many of the traditional UNIX
> implementations.    IIRC they did not support BSD's mmap -- but check the

It sounds like they could have supported mmap() easily.  I'd love to see
this kernel, it sounds to me like it was SunOS with nicely done SMP 
support.  The guy that said he'd never seen anything like it before or
since, just makes me want to see it more.

I know someone who was friends with one of the kernel guys, haven't talked
to her in years but I'll see if I can find anything.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 18:36     ` Larry McVoy
@ 2022-11-12 19:36       ` Clem Cole
  2022-11-13  1:56         ` Larry McVoy
  0 siblings, 1 reply; 23+ messages in thread
From: Clem Cole @ 2022-11-12 19:36 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs

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

To be honest, I've forgotten many (most) of the details.  But that sounds
about right.  As I remember it, it was like SunOS.  The key point was that
the kernel only had one view of the memory system period, no FS
buffer cache etc...which was a departure from many of the traditional UNIX
implementations.    IIRC they did not support BSD's mmap -- but check the
SVR3 docs to be sure -- they had the SVR3 user interfaces but none of the
BSD ones.  They did support the System V shared memory, however.  I do seem
to remember there was something funny in the driver interfaces, it was just
like UNIX only different, and that causes some heartache - but it was
fairly straightforward to move a DMA driver like getting a VME Xylogics
tape controller to work, but it took a little tweaking.  I've forgotten
exactly why that was --  it's been a long time ago.

Clem
ᐧ

On Sat, Nov 12, 2022 at 1:36 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Sat, Nov 12, 2022 at 01:04:30PM -0500, Clem Cole wrote:
> > On Sat, Nov 12, 2022 at 11:52 AM <arnold@skeeve.com> wrote:
> > > DG-UX was a pretty generic SVR3
> > >
> > User space was generic.   But the SVR3/88K kernel was a heavy rewrite.
> >  LCC did a lot of work with DG adding stuff too it -- it was very well
> done
> > by the DG team in NC.   The memory and FS was well integrated.
>
> So read()/write()/mmap() all shared the same cache like SunOS?  In SunOS
> the
> only things not in the page cache were directories and inodes.  All data
> pages had one, and only one, place to be (ZFS broke this in Solaris,
> which has always blown my mind).
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 19:16 ` Dave Horsfall
@ 2022-11-12 19:31   ` Clem Cole
  0 siblings, 0 replies; 23+ messages in thread
From: Clem Cole @ 2022-11-12 19:31 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

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

On Sat, Nov 12, 2022 at 2:16 PM Dave Horsfall <dave@horsfall.org> wrote:

>
>
> That would be the "NUXI" bug (byte-swapped words).
>
Yep -- the reversal in my email was typo and then dyslexia on my part. ;-)

FYI: I was there when the guy from Cleveland State gave the paper.  It was
a riot.
ᐧ

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 15:54 [TUHS] " Clem Cole
  2022-11-12 16:09 ` [TUHS] " Larry McVoy
  2022-11-12 16:52 ` arnold
@ 2022-11-12 19:16 ` Dave Horsfall
  2022-11-12 19:31   ` Clem Cole
  2 siblings, 1 reply; 23+ messages in thread
From: Dave Horsfall @ 2022-11-12 19:16 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

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

On Sat, 12 Nov 2022, Clem Cole wrote:

[ ... ]

> (the infamous 'NUIX' bug from the Series/1 port probably being my 
> favorite tale).

That would be the "NUXI" bug (byte-swapped words).

> So to the hive mind, did anyone (DG themselves or a University) ever 
> build 16 or 32-bit tools for the DG architectures and do a UNIX port, 
> and if so, does anyone know what became of those efforts?  Is this 
> something that needs to be in the TUHS archives also?

I remember Tracey Kidder's "The Soul of a New Machine"...  It ran some 
proprietary system, though.

-- Dave

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 18:04   ` Clem Cole
@ 2022-11-12 18:36     ` Larry McVoy
  2022-11-12 19:36       ` Clem Cole
  0 siblings, 1 reply; 23+ messages in thread
From: Larry McVoy @ 2022-11-12 18:36 UTC (permalink / raw)
  To: Clem Cole; +Cc: tuhs

On Sat, Nov 12, 2022 at 01:04:30PM -0500, Clem Cole wrote:
> On Sat, Nov 12, 2022 at 11:52 AM <arnold@skeeve.com> wrote:
> > DG-UX was a pretty generic SVR3
> >
> User space was generic.   But the SVR3/88K kernel was a heavy rewrite.
>  LCC did a lot of work with DG adding stuff too it -- it was very well done
> by the DG team in NC.   The memory and FS was well integrated.  

So read()/write()/mmap() all shared the same cache like SunOS?  In SunOS the
only things not in the page cache were directories and inodes.  All data
pages had one, and only one, place to be (ZFS broke this in Solaris,
which has always blown my mind).
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 16:52 ` arnold
                     ` (3 preceding siblings ...)
  2022-11-12 17:37   ` Brad Spencer
@ 2022-11-12 18:04   ` Clem Cole
  2022-11-12 18:36     ` Larry McVoy
  4 siblings, 1 reply; 23+ messages in thread
From: Clem Cole @ 2022-11-12 18:04 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, simh

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

On Sat, Nov 12, 2022 at 11:52 AM <arnold@skeeve.com> wrote:

>
>
> DG-UX was a pretty generic SVR3
>
User space was generic.   But the SVR3/88K kernel was a heavy rewrite.
 LCC did a lot of work with DG adding stuff too it -- it was very well done
by the DG team in NC.   The memory and FS was well integrated.  Of all the
UNIX kernels we did work, it was pretty much the easiest to learn and
modify.

ᐧ

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 17:09   ` Miod Vallat
  2022-11-12 17:12     ` Warner Losh
@ 2022-11-12 17:39     ` arnold
  1 sibling, 0 replies; 23+ messages in thread
From: arnold @ 2022-11-12 17:39 UTC (permalink / raw)
  To: miod, arnold; +Cc: tuhs

Miod Vallat <miod@online.fr> wrote:

> > There was a guy who worked at DG and contributed a lot of the Motorola
> > 88000 code to GCC whose name I don't remember, although I met him
> > at a USENIX.  If someone else remembers who this is, maybe he can
> > be tracked down for more info.
>
> I suppose you're referring to Tom Wood here?

That doesn't sound right... I wish I could remember. :-(

Arnold

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 16:52 ` arnold
                     ` (2 preceding siblings ...)
  2022-11-12 17:13   ` David Barto
@ 2022-11-12 17:37   ` Brad Spencer
  2022-11-12 18:04   ` Clem Cole
  4 siblings, 0 replies; 23+ messages in thread
From: Brad Spencer @ 2022-11-12 17:37 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, simh

arnold@skeeve.com writes:

> I'm pretty sure that DG never ported DG-UX to the Nova. There was
> a native port to the Eclipse (32 bit).  There was also a Eunice-style
> Unix environment that sat on top of their native OS, whatever it was
> called.

AOS and then AOS/VS for the Eclipse.  In the late 1980s and early 1990s
I messed a whole lot with AOS/VS at the university I was at.  It was
very much Not Unix.  Towards the end of my time there, a number of
programs that traditionally would be on a Unix system, things like
sendmail, ftpd, and etc.. were natively ported to AOS/VS.  The ports
were probably done as best as they could have been, but they lacked a
whole lot of ability if I remember things correctly.

After I left, the university acquired a DG of some sort that ran DG-UX
(or DGUX).

[snip]

>
> Arnold





-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 16:52 ` arnold
  2022-11-12 17:05   ` Larry McVoy
  2022-11-12 17:09   ` Miod Vallat
@ 2022-11-12 17:13   ` David Barto
  2022-11-12 17:37   ` Brad Spencer
  2022-11-12 18:04   ` Clem Cole
  4 siblings, 0 replies; 23+ messages in thread
From: David Barto @ 2022-11-12 17:13 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: tuhs, simh

I worked on the DG-UX software porting device drivers to it.

It wasn’t a Unix port, it was a complete re-write from the ground up.

The interfaces to the drivers was different and the internal locking mechanisms
were unique to the OS. I’d never seen anything like it before, or after.

	David

> On Nov 12, 2022, at 8:52 AM, arnold@skeeve.com wrote:
> 
> I'm pretty sure that DG never ported DG-UX to the Nova. There was
> a native port to the Eclipse (32 bit).  There was also a Eunice-style
> Unix environment that sat on top of their native OS, whatever it was
> called.
> 
> When I was working there, DG gave the Georgia Tech School of Information
> and Computer Science an Eclipse running their native OS in the early
> mid-80s. I didn't do much with it, and I suspect that nobody else there
> did either.
> 
> I'm bcc-ing Scott Lee, who was the admin for that machine at the time;
> maybe he remembers more.
> 
> There was a guy who worked at DG and contributed a lot of the Motorola
> 88000 code to GCC whose name I don't remember, although I met him
> at a USENIX.  If someone else remembers who this is, maybe he can
> be tracked down for more info.
> 
> DG-UX was a pretty generic SVR3 (and later SVR4) system, IIRC.
> 
> In any case, DG-UX on the Eclipse preceded it on the 88000.
> 
> I hope this helps,
> 
> Arnold
> 
> P.S. For the youngsters here who've never heard of it, I highly
> recommend Tracy Kidder's "The Soul of a New Machine" about the
> development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1).
> 
> It was originally written in 1982 - 40 years ago!
> 
> Clem Cole <clemc@ccc.com> wrote:
> 
>> This recent activity on the simh mailing list WRT to DG Nova and
>> Ecpilse got me wondering.  At Locus in the 80s and 90s, we did a lot of
>> work with DG and DG-UX with their later MP-based ports using commercially
>> available microprocessors (which I have reported was a very nicely done
>> system, easy to work on, the locks tended to scale well, e*tc*.).
>> 
>> But I am trying to remember if C or UNIX was on a Nova or an Eclipse.  This
>> could be my failed memory, given that so many people ported V7 in the late
>> 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my
>> favorite tale).  So to the hive mind, did anyone (DG themselves or a
>> University) ever build 16 or 32-bit tools for the DG architectures and do a
>> UNIX port, and if so, does anyone know what became of those efforts?  Is
>> this something that needs to be in the TUHS archives also?
>> 
>> Clem
>> ???


^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 17:09   ` Miod Vallat
@ 2022-11-12 17:12     ` Warner Losh
  2022-11-12 17:39     ` arnold
  1 sibling, 0 replies; 23+ messages in thread
From: Warner Losh @ 2022-11-12 17:12 UTC (permalink / raw)
  To: Miod Vallat; +Cc: The Eunuchs Hysterical Society

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

On Sat, Nov 12, 2022, 10:10 AM Miod Vallat <miod@online.fr> wrote:

> > There was a guy who worked at DG and contributed a lot of the Motorola
> > 88000 code to GCC whose name I don't remember, although I met him
> > at a USENIX.  If someone else remembers who this is, maybe he can
> > be tracked down for more info.
>
> I suppose you're referring to Tom Wood here?
>
> > P.S. For the youngsters here who've never heard of it, I highly
> > recommend Tracy Kidder's "The Soul of a New Machine" about the
> > development of the Eclipse. (
> https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1
> ).
> >
> > It was originally written in 1982 - 40 years ago!
>
> Seconded - definitely a must read; even if technology has evolved a lot
> since then, management and human factors have not.
>

Bring them in, burn them out, sweat every hour out of them... call it
excellence. Bah

Warner

>

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

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 16:52 ` arnold
  2022-11-12 17:05   ` Larry McVoy
@ 2022-11-12 17:09   ` Miod Vallat
  2022-11-12 17:12     ` Warner Losh
  2022-11-12 17:39     ` arnold
  2022-11-12 17:13   ` David Barto
                     ` (2 subsequent siblings)
  4 siblings, 2 replies; 23+ messages in thread
From: Miod Vallat @ 2022-11-12 17:09 UTC (permalink / raw)
  To: arnold; +Cc: tuhs

> There was a guy who worked at DG and contributed a lot of the Motorola
> 88000 code to GCC whose name I don't remember, although I met him
> at a USENIX.  If someone else remembers who this is, maybe he can
> be tracked down for more info.

I suppose you're referring to Tom Wood here?

> P.S. For the youngsters here who've never heard of it, I highly
> recommend Tracy Kidder's "The Soul of a New Machine" about the
> development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1).
> 
> It was originally written in 1982 - 40 years ago!

Seconded - definitely a must read; even if technology has evolved a lot
since then, management and human factors have not.

Miod

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 16:52 ` arnold
@ 2022-11-12 17:05   ` Larry McVoy
  2022-11-12 17:09   ` Miod Vallat
                     ` (3 subsequent siblings)
  4 siblings, 0 replies; 23+ messages in thread
From: Larry McVoy @ 2022-11-12 17:05 UTC (permalink / raw)
  To: arnold; +Cc: tuhs, simh

On Sat, Nov 12, 2022 at 09:52:05AM -0700, arnold@skeeve.com wrote:
> P.S. For the youngsters here who've never heard of it, I highly
> recommend Tracy Kidder's "The Soul of a New Machine" about the
> development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1).
> 
> It was originally written in 1982 - 40 years ago!

That's a great read, +1.

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 15:54 [TUHS] " Clem Cole
  2022-11-12 16:09 ` [TUHS] " Larry McVoy
@ 2022-11-12 16:52 ` arnold
  2022-11-12 17:05   ` Larry McVoy
                     ` (4 more replies)
  2022-11-12 19:16 ` Dave Horsfall
  2 siblings, 5 replies; 23+ messages in thread
From: arnold @ 2022-11-12 16:52 UTC (permalink / raw)
  To: tuhs, simh, clemc

I'm pretty sure that DG never ported DG-UX to the Nova. There was
a native port to the Eclipse (32 bit).  There was also a Eunice-style
Unix environment that sat on top of their native OS, whatever it was
called.

When I was working there, DG gave the Georgia Tech School of Information
and Computer Science an Eclipse running their native OS in the early
mid-80s. I didn't do much with it, and I suspect that nobody else there
did either.

I'm bcc-ing Scott Lee, who was the admin for that machine at the time;
maybe he remembers more.

There was a guy who worked at DG and contributed a lot of the Motorola
88000 code to GCC whose name I don't remember, although I met him
at a USENIX.  If someone else remembers who this is, maybe he can
be tracked down for more info.

DG-UX was a pretty generic SVR3 (and later SVR4) system, IIRC.

In any case, DG-UX on the Eclipse preceded it on the 88000.

I hope this helps,

Arnold

P.S. For the youngsters here who've never heard of it, I highly
recommend Tracy Kidder's "The Soul of a New Machine" about the
development of the Eclipse. (https://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/0316491977/ref=sr_1_1?keywords=the+soul+of+a+new+machine+by+tracy+kidder&qid=1668271720&sprefix=the+soul+of+a+new%2Caps%2C233&sr=8-1).

It was originally written in 1982 - 40 years ago!

Clem Cole <clemc@ccc.com> wrote:

> This recent activity on the simh mailing list WRT to DG Nova and
> Ecpilse got me wondering.  At Locus in the 80s and 90s, we did a lot of
> work with DG and DG-UX with their later MP-based ports using commercially
> available microprocessors (which I have reported was a very nicely done
> system, easy to work on, the locks tended to scale well, e*tc*.).
>
> But I am trying to remember if C or UNIX was on a Nova or an Eclipse.  This
> could be my failed memory, given that so many people ported V7 in the late
> 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my
> favorite tale).  So to the hive mind, did anyone (DG themselves or a
> University) ever build 16 or 32-bit tools for the DG architectures and do a
> UNIX port, and if so, does anyone know what became of those efforts?  Is
> this something that needs to be in the TUHS archives also?
>
> Clem
> ???

^ permalink raw reply	[flat|nested] 23+ messages in thread

* [TUHS] Re: DG UNIX History
  2022-11-12 15:54 [TUHS] " Clem Cole
@ 2022-11-12 16:09 ` Larry McVoy
  2022-11-12 16:52 ` arnold
  2022-11-12 19:16 ` Dave Horsfall
  2 siblings, 0 replies; 23+ messages in thread
From: Larry McVoy @ 2022-11-12 16:09 UTC (permalink / raw)
  To: Clem Cole; +Cc: The Eunuchs Hysterical Society, simh

I dunno.  I've heard DG did a pretty much from the ground up rewrite of
Unix to make it scale well on SMP machines.  I've never seen the source
or used DG-UX, so it's all heresay.  If anyone has more info than what
Clem said, I'm all ears.

The reason I'm interested is the original model of disabling interrupts
really isn't pleasant on an SMP but people tried to evolve it towards
something that scaled.  It seems like DG went at it starting over,
designing SMP in from the start.  Be interesting to understand what
they did.  Sequent as well.

On Sat, Nov 12, 2022 at 10:54:16AM -0500, Clem Cole wrote:
> This recent activity on the simh mailing list WRT to DG Nova and
> Ecpilse got me wondering.  At Locus in the 80s and 90s, we did a lot of
> work with DG and DG-UX with their later MP-based ports using commercially
> available microprocessors (which I have reported was a very nicely done
> system, easy to work on, the locks tended to scale well, e*tc*.).
> 
> But I am trying to remember if C or UNIX was on a Nova or an Eclipse.  This
> could be my failed memory, given that so many people ported V7 in the late
> 1970s (the infamous 'NUIX' bug from the Series/1 port probably being my
> favorite tale).  So to the hive mind, did anyone (DG themselves or a
> University) ever build 16 or 32-bit tools for the DG architectures and do a
> UNIX port, and if so, does anyone know what became of those efforts?  Is
> this something that needs to be in the TUHS archives also?
> 
> Clem
> ???

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2022-11-15 17:49 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-14 22:11 [TUHS] Re: DG UNIX History Paul Ruizendaal
2022-11-14 22:31 ` Clem Cole
2022-11-14 23:54   ` Warner Losh
2022-11-15  6:03     ` Theodore Ts'o
2022-11-15 15:11       ` Larry McVoy
2022-11-15 15:48         ` Bakul Shah
2022-11-15 17:47       ` Warner Losh
2022-11-15  1:21   ` Stuff Received
  -- strict thread matches above, loose matches on Subject: below --
2022-11-14 11:44 arnold
2022-11-12 15:54 [TUHS] " Clem Cole
2022-11-12 16:09 ` [TUHS] " Larry McVoy
2022-11-12 16:52 ` arnold
2022-11-12 17:05   ` Larry McVoy
2022-11-12 17:09   ` Miod Vallat
2022-11-12 17:12     ` Warner Losh
2022-11-12 17:39     ` arnold
2022-11-12 17:13   ` David Barto
2022-11-12 17:37   ` Brad Spencer
2022-11-12 18:04   ` Clem Cole
2022-11-12 18:36     ` Larry McVoy
2022-11-12 19:36       ` Clem Cole
2022-11-13  1:56         ` Larry McVoy
2022-11-12 19:16 ` Dave Horsfall
2022-11-12 19:31   ` Clem Cole

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).