10 Jan
2017
10 Jan
'17
3:12 p.m.
I have been trolling these many threads lately of interest. So thought I should chip in.
"SVr4 was not based on SunOS, although it incorporated
many of the best features of SunOS 4.x”.
IMHO this statement is almost true (there were many great features from BSD too!).
SunOS 5.0 was ported from SVR4 in early 1991 and released as Solaris 2.0 in 1992 for
desktop only.
Back in the late 80s, Sun and AT&T partnered development efforts so it’s no surprise
that SunOS morphed into SVR4. Indeed it was Sun and AT&T who were the founding members
of Unix International…with an aim to provide direction and unification of SVR4.
I remember when I went to work for Sun (much later in 2003), and found that the code base
was remarkably similar to the SVR4 code (if not exact in many areas).
Here’s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure this is
correct. But I am sure many of you will put me right if I am wrong ;)
From BSD:
TCP/IP
C Shell
Sockets
Process groups and job Control
Some signals
FFS in UFS guise
Multi groups/file ownership
Some system calls
COFF
From SunOS:
vnodes
VFS
VM
mmap
LWP and kernel threads
/proc
Dynamic linking extensions
NFS
RPC
XDR
From SVR3:
.so libs
revamped signals and trampoline code
VFSSW
RFS
STREAMS and TLI
IPC (Shared memory, Message queues, semaphores)
Additional features in SVR4 from USL:
new boot process.
ksh
real time extensions
Service access facility
Enhancements to STREAMS
ELF
4:24 p.m.
Larry McVoy <lm(a)mcvoy.com> wrote:
.so is a name introduced by SunOS-4
What Svr3 had, was shared libraries that have been installed in the kernel
during boot up into multi-user mode using a special program. In order to
manage this, you needed to have a global library manager that defined start
addresses for the load addresses of the libraries.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
On Tue, Jan 10, 2017 at 03:12:19PM +0000, Berny
Goodheart wrote:
and I believe that Roger Faulkner did come from AT&T
From SunOS:
/proc
Pretty sure /proc was not a SunOS thing. From SVR3:
.so libs
If you mean shared libraries, SunOS had those. If it's more nuanced
than that, I'd defer to Gingell.
4:32 p.m.
On 10 Jan 2017, at 16:24, Joerg Schilling
<schily(a)schily.net> wrote:
Larry McVoy <lm(a)mcvoy.com> wrote:
Yes. And I should know this as I communicated and met with him on several occasions when I
was developing /proc for Janus (Linux binary emulation) on Solaris x86.
So, I was defo wrong on this. /proc was done by Roger at AT&T (maybe USL). I recall
him telling me that he was not the original author though and that it came from PWB.
On Tue, Jan 10, 2017 at 03:12:19PM +0000, Berny
Goodheart wrote:
and I believe that Roger Faulkner did come from AT&T From SunOS:
/proc
Pretty sure /proc was not a SunOS thing. From
SVR3:
.so libs
If you mean shared libraries, SunOS had those. If it's more nuanced
than that, I'd defer to Gingell.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
4:40 p.m.
On 1/10/17 11:32 AM, Berny Goodheart wrote:
/proc was done by Roger at AT&T (maybe USL). I recall him telling me that
he was not the original author though and that it came from PWB.
The original implementation was done by Tom Killian for 8th Edition. I
think Roger used that as inspiration, not sure about the code.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
On 10 Jan 2017, at 16:24, Joerg Schilling
<schily(a)schily.net> wrote:
Larry McVoy <lm(a)mcvoy.com> wrote:
Yes. And I should know this as I communicated and met with him on several occasions when
I was developing /proc for Janus (Linux binary emulation) on Solaris x86.
So, I was defo wrong on this. On Tue, Jan 10, 2017 at 03:12:19PM +0000, Berny
Goodheart wrote:
and I believe that Roger Faulkner did come from AT&T From SunOS:
/proc
Pretty sure /proc was not a SunOS thing.
4:41 p.m.
Berny Goodheart <berny(a)berwynlodge.com> wrote:
Yes. And I should know this as I communicated and met with him on several occasions when
I was developing /proc for Janus (Linux binary emulation) on Solaris x86.
So, I was defo wrong on this. /proc was done by Roger at AT&T (maybe USL). I recall
him telling me that he was not the original author though and that it came from PWB.
AFAIK, Roger was the original author for ProcFS-II that was introduced later in
SunOS-5 (I believe it was Solaris-2.6) and introduced subdirectories.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Pretty sure /proc was not a SunOS thing.
and I believe that Roger Faulkner did come from AT&T
4:20 p.m.
Berny Goodheart <berny(a)berwynlodge.com> wrote:
Here???s the breakdown of SVR4 kernel lineage as I
recall it. I am pretty sure this is correct. But I am sure many of you will put me right
if I am wrong ;)
From BSD:
TCP/IP <=== NO, Svr4 uses a STREAMS based TCP/IP stack
C Shell
Sockets <=== NO, BSD has sockets in kernel, SVr4 in
userland
Process groups and job Control
Some signals
FFS in UFS guise <=== NO, rather taken from SunOS-4
Multi groups/file ownership
Some system calls
COFF <=== NO, COFF was from SysV and deprecated in Svr4
From SunOS:
vnodes
VFS
VM
mmap
LWP and kernel threads
/proc <=== NO, /proc did not exist in SunOS-4
Dynamic linking extensions
NFS
RPC
XDR
From SVR3:
.so libs <=== What should this be?
I am not even sure whether SVr4 included
backwards compatibility for the SVr3
"installed" shared libraries.
revamped signals and trampoline code +++++sigset() was
not in SVr2, I believe
it was not
available in svr3 as
well and rather invented for
Svr4
VFSSW <=== NO, this is
from SunOS-4
RFS
STREAMS and TLI <=== SVr3 did not have STREAMS
IPC (Shared memory, Message queues, semaphores) <=== Already in SunOS-4
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
4:34 p.m.
The old saw that I wish I had said "great men stand on the shoulders of greater men,
computer scientist like to step on their toes."
The problem I have with this sort of accounting is it leaves out where different groups
took these ideas and integrated them. Others that come later loss that history. For
instance ip/tcp came from bbn, /proc came from research, job control came from MIT,
fsck from CMU etc.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
On Jan 10, 2017, at 8:20 AM, Joerg Schilling
<schily(a)schily.net> wrote:
Berny Goodheart <berny(a)berwynlodge.com> wrote:
Here???s the breakdown of SVR4 kernel lineage as
I recall it. I am pretty sure this is correct. But I am sure many of you will put me right
if I am wrong ;)
From BSD:
TCP/IP <=== NO, Svr4 uses a STREAMS based TCP/IP stack
C Shell
Sockets <=== NO, BSD has sockets in kernel, SVr4 in
userland
Process groups and job Control
Some signals
FFS in UFS guise <=== NO, rather taken from SunOS-4
Multi groups/file ownership
Some system calls
COFF <=== NO, COFF was from SysV and deprecated in Svr4
From SunOS:
vnodes
VFS
VM
mmap
LWP and kernel threads
/proc <=== NO, /proc did not exist in SunOS-4
Dynamic linking extensions
NFS
RPC
XDR
From SVR3:
.so libs <=== What should this be?
I am not even
sure whether SVr4 included
backwards compatibility for the SVr3
"installed" shared libraries.
revamped signals and trampoline code
+++++sigset() was not in SVr2, I believe
it was not
available in svr3 as
well and rather invented for
Svr4
VFSSW <=== NO, this is from
SunOS-4
RFS
STREAMS and TLI <=== SVr3 did not have STREAMS
IPC (Shared memory, Message queues, semaphores) <=== Already in SunOS-4
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
4:38 p.m.
On 1/10/17 11:34 AM, Clem cole wrote:
job control came from MIT
The original concepts might have, but the BSD implementation was done by
Jim Kulp at IIASA before it was folded into 4.1 BSD.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://cnswww.cns.cwru.edu/~chet/
4:57 p.m.
On 10 Jan 2017, at 16:20, Joerg Schilling
<schily(a)schily.net> wrote:
Berny Goodheart <berny(a)berwynlodge.com> wrote:
> Here???s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure this
is correct. But I am sure many of you will put me right if I am wrong ;)
>
> From BSD:
> TCP/IP <=== NO, Svr4 uses a STREAMS based TCP/IP stack
Correct. Sort of. in SVR4 it was defo STREAMS based. But in earlier SVRx versions it was
the BSD stuff.
C Shell
Sockets <=== NO, BSD has sockets in kernel, SVr4 in
userland > Process groups and job Control
> Some signals
> FFS in UFS guise <=== NO, rather taken from SunOS-4
I am not sure
on this so I will agree ;)
> Multi groups/file ownership
> Some system calls
> COFF <=== NO, COFF was from SysV and deprecated in
Svr4
I defo have this one wrong. You are correct.
>
> From SunOS:
> vnodes
> VFS
> VM
> mmap
> LWP and kernel threads
> /proc <=== NO, /proc did not exist in SunOS-4
Yes, it came from Roger at AT&T
Dynamic
linking extensions
NFS
RPC
XDR
From SVR3:
.so libs <=== What should this be?
I am not even sure whether SVr4 included
backwards compatibility for the SVr3
"installed" shared libraries.
revamped signals and trampoline code
+++++sigset() was not in SVr2, I believe
it was not available in svr3 as
well and rather invented for
Svr4 > VFSSW <=== NO,
this is from SunOS-4
I am prety sure this was from AT&T albeit, it was probably
Sun developed.
> RFS
> STREAMS and TLI <=== SVr3 did not have STREAMS
SVR3 defo had
STREAMS.
> IPC (Shared memory, Message queues, semaphores)
<=== Already in SunOS-4
But it was in SysV before SunOS-4. Much of Solaris IPC
came from the SysV code together with POSIX IPC and some extras….doors.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
5:10 p.m.
Berny Goodheart <berny(a)berwynlodge.com> wrote:
Doors are a backport from the "Spring" operating system from Bill Joy that he
developed in Colorado after the SVr4 task was finished around 1992.
Spring was send to universities and research institutes in 1996 and then shut
down, but doors were backported to Solaris for "nscd" the name service cache
daemon.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
> IPC
(Shared memory, Message queues, semaphores) <=== Already in SunOS-4
But it was
in SysV before SunOS-4. Much of Solaris IPC came from the SysV code together with POSIX
IPC and some extras?.doors. 
5:47 p.m.
On Tue, Jan 10, 2017 at 8:20 AM, Joerg Schilling <schily(a)schily.net> wrote:
Berny Goodheart <berny(a)berwynlodge.com> wrote:
> Here???s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure this
is correct. But I am sure many of you will put me right if I am wrong ;)
>
> From BSD:
> TCP/IP <=== NO, Svr4 uses a STREAMS based TCP/IP stack
svr4's stack is derived from BSD with a STREAMS packaging. These files
were listed as "in AT&T's code w/o BSD headers" in the countersuit for
the infamous AT&T lawsuit.
Warner
6:28 p.m.
On Tue, Jan 10, 2017 at 09:47:28AM -0800, Warner Losh wrote:
On Tue, Jan 10, 2017 at 8:20 AM, Joerg Schilling
<schily(a)schily.net> wrote:
Yeah, I think Convergent did the STREAMS packaging, then Lachman bought
the stack, I ported it twice (ETA & SCO), then I believe it was Bill
Coleman (not positive on the name, it was the VP of networking) at Sun
that bought rights to the stack from Lachman under pretty unfavorable
terms, then Sun got unhappy with the terms (and the performance),
contracted with Mentat to do a new stack and I think that stack is what
remains in Solaris.
Berny Goodheart <berny(a)berwynlodge.com>
wrote:
> Here???s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure this
is correct. But I am sure many of you will put me right if I am wrong ;)
>
> From BSD:
> TCP/IP <=== NO, Svr4 uses a STREAMS based TCP/IP stack
svr4's stack is derived from BSD with a STREAMS packaging. These files
were listed as "in AT&T's code w/o BSD headers" in the countersuit for
the infamous AT&T lawsuit.
6:33 p.m.
On Tue, Jan 10, 2017 at 10:28 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
On Tue, Jan 10, 2017 at 09:47:28AM -0800, Warner Losh
wrote:
I did some work on the Lachman stack for sysvr4 machines at Wollongong
in 89 or so as well... It was very BSDish code that had been involved
in a horrific traffic accident and rebuilt in a STREAMS framework. I'm
not at all surprised that it didn't scale, because at the time it
barely worked...
Warner
On Tue, Jan 10, 2017 at 8:20 AM, Joerg Schilling
<schily(a)schily.net> wrote:
Yeah, I think Convergent did the STREAMS packaging, then Lachman bought
the stack, I ported it twice (ETA & SCO), then I believe it was Bill
Coleman (not positive on the name, it was the VP of networking) at Sun
that bought rights to the stack from Lachman under pretty unfavorable
terms, then Sun got unhappy with the terms (and the performance),
contracted with Mentat to do a new stack and I think that stack is what
remains in Solaris. Berny Goodheart <berny(a)berwynlodge.com>
wrote:
> Here???s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure this
is correct. But I am sure many of you will put me right if I am wrong ;)
>
> From BSD:
> TCP/IP <=== NO, Svr4 uses a STREAMS based TCP/IP stack
svr4's stack is derived from BSD with a STREAMS packaging. These files
were listed as "in AT&T's code w/o BSD headers" in the countersuit for
the infamous AT&T lawsuit.
6:42 p.m.
On Tue, Jan 10, 2017 at 10:33:59AM -0800, Warner Losh wrote:
On Tue, Jan 10, 2017 at 10:28 AM, Larry McVoy
<lm(a)mcvoy.com> wrote:
Yup, been there, lived that. Until Mentat came along it was the only game
in town. I don't normally tell people I'm the guy that gave SCO networking
because it "barely worked" as you say.
I did get SCO to ship sw (STREAMS watch) that was sort of like a top for
STREAMS - it was useful to run this while beating on the stack and then
go tune the internal limits for better performance. I can't imagine
anyone wants this any more, or if it even runs, but it's my copyright
and I stuck a copy in http://mcvoy.com/lm/sw.shar
On Tue, Jan 10, 2017 at 09:47:28AM -0800, Warner
Losh wrote:
I did some work on the Lachman stack for sysvr4 machines at Wollongong
in 89 or so as well... It was very BSDish code that had been involved
in a horrific traffic accident and rebuilt in a STREAMS framework. I'm
not at all surprised that it didn't scale, because at the time it
barely worked... On Tue, Jan 10, 2017 at 8:20 AM, Joerg Schilling
<schily(a)schily.net> wrote:
Yeah, I think Convergent did the STREAMS packaging, then Lachman bought
the stack, I ported it twice (ETA & SCO), then I believe it was Bill
Coleman (not positive on the name, it was the VP of networking) at Sun
that bought rights to the stack from Lachman under pretty unfavorable
terms, then Sun got unhappy with the terms (and the performance),
contracted with Mentat to do a new stack and I think that stack is what
remains in Solaris. Berny Goodheart <berny(a)berwynlodge.com>
wrote:
> Here???s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure this
is correct. But I am sure many of you will put me right if I am wrong ;)
>
> From BSD:
> TCP/IP <=== NO, Svr4 uses a STREAMS based TCP/IP stack
svr4's stack is derived from BSD with a STREAMS packaging. These files
were listed as "in AT&T's code w/o BSD headers" in the countersuit for
the infamous AT&T lawsuit.
7:21 p.m.
Correct- that was the path as I know it. i.e. ITS gave Unix more and job control.
Which is my point. When some one starts pontificating about how SYS/BSD/Linux this that
or the other thing - often the idea came elsewhere. Wide distribution and use was
supplied by the XXX Channel but there were many many fathers and mothers
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
On Jan 10, 2017, at 10:42 AM, Larry McVoy
<lm(a)mcvoy.com> wrote:
On Tue, Jan 10, 2017 at 10:33:59AM -0800, Warner
Losh wrote:
Yup, been there, lived that. Until Mentat came along it was the only game
in town. I don't normally tell people I'm the guy that gave SCO networking
because it "barely worked" as you say.
I did get SCO to ship sw (STREAMS watch) that was sort of like a top for
STREAMS - it was useful to run this while beating on the stack and then
go tune the internal limits for better performance. I can't imagine
anyone wants this any more, or if it even runs, but it's my copyright
and I stuck a copy in http://mcvoy.com/lm/sw.shar
On Tue, Jan 10, 2017 at 10:28 AM, Larry McVoy
<lm(a)mcvoy.com> wrote:
I did some work on the Lachman stack for sysvr4 machines at Wollongong
in 89 or so as well... It was very BSDish code that had been involved
in a horrific traffic accident and rebuilt in a STREAMS framework. I'm
not at all surprised that it didn't scale, because at the time it
barely worked... On Tue, Jan 10, 2017 at 09:47:28AM -0800, Warner
Losh wrote:
> On Tue, Jan 10, 2017 at 8:20 AM, Joerg Schilling <schily(a)schily.net> wrote:
> Berny Goodheart <berny(a)berwynlodge.com> wrote:
>
>> Here???s the breakdown of SVR4 kernel lineage as I recall it. I am pretty sure
this is correct. But I am sure many of you will put me right if I am wrong ;)
>>
>> From BSD:
>> TCP/IP <=== NO, Svr4 uses a STREAMS based TCP/IP stack
svr4's stack is derived from BSD with a STREAMS packaging. These files
were listed as "in AT&T's code w/o BSD headers" in the countersuit for
the infamous AT&T lawsuit.
Yeah, I think Convergent did the STREAMS packaging, then Lachman bought
the stack, I ported it twice (ETA & SCO), then I believe it was Bill
Coleman (not positive on the name, it was the VP of networking) at Sun
that bought rights to the stack from Lachman under pretty unfavorable
terms, then Sun got unhappy with the terms (and the performance),
contracted with Mentat to do a new stack and I think that stack is what
remains in Solaris.
7:41 p.m.
Looks like apples mail screwed up the repl. That was supported to be directed at
Chet's comment about noting Jim Kulp great work implementing ITS style job control
that joy took into BSD
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
On Jan 10, 2017, at 11:21 AM, Clem cole
<clemc(a)ccc.com> wrote:
Correct- that was the path as I know it. i.e. ITS gave Unix more and job control.
Which is my point. When some one starts pontificating about how SYS/BSD/Linux this
that or the other thing - often the idea came elsewhere. Wide distribution and use was
supplied by the XXX Channel but there were many many fathers and mothers
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>> On Jan 10, 2017, at 10:42 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
>>
>>> On Tue, Jan 10, 2017 at 10:33:59AM -0800, Warner Losh wrote:
>>>> On Tue, Jan 10, 2017 at 10:28 AM, Larry McVoy <lm(a)mcvoy.com> wrote:
>>>>> On Tue, Jan 10, 2017 at 09:47:28AM -0800, Warner Losh wrote:
>>>>> On Tue, Jan 10, 2017 at 8:20 AM, Joerg Schilling
<schily(a)schily.net> wrote:
>>>>> Berny Goodheart <berny(a)berwynlodge.com> wrote:
>>>>>
>>>>>> Here???s the breakdown of SVR4 kernel lineage as I recall it. I
am pretty sure this is correct. But I am sure many of you will put me right if I am wrong
;)
>>>>>>
>>>>>> From BSD:
>>>>>> TCP/IP <=== NO, Svr4 uses a STREAMS
based TCP/IP stack
>>>>
>>>> svr4's stack is derived from BSD with a STREAMS packaging. These
files
>>>> were listed as "in AT&T's code w/o BSD headers" in the
countersuit for
>>>> the infamous AT&T lawsuit.
>>>
>>> Yeah, I think Convergent did the STREAMS packaging, then Lachman bought
>>> the stack, I ported it twice (ETA & SCO), then I believe it was Bill
>>> Coleman (not positive on the name, it was the VP of networking) at Sun
>>> that bought rights to the stack from Lachman under pretty unfavorable
>>> terms, then Sun got unhappy with the terms (and the performance),
>>> contracted with Mentat to do a new stack and I think that stack is what
>>> remains in Solaris.
>>
>> I did some work on the Lachman stack for sysvr4 machines at Wollongong
>> in 89 or so as well... It was very BSDish code that had been involved
>> in a horrific traffic accident and rebuilt in a STREAMS framework. I'm
>> not at all surprised that it didn't scale, because at the time it
>> barely worked...
>
> Yup, been there, lived that. Until Mentat came along it was the only game
> in town. I don't normally tell people I'm the guy that gave SCO networking
> because it "barely worked" as you say.
>
> I did get SCO to ship sw (STREAMS watch) that was sort of like a top for
> STREAMS - it was useful to run this while beating on the stack and then
> go tune the internal limits for better performance. I can't imagine
> anyone wants this any more, or if it even runs, but it's my copyright
> and I stuck a copy in http://mcvoy.com/lm/sw.shar
>
11 Jan
11 Jan
9:03 p.m.
On Tue, Jan 10, 2017 at 2:21 PM, Clem cole <clemc(a)ccc.com> wrote:
Correct- that was the path as I know it. i.e. ITS
gave Unix more and job
control.
Which is my point. When some one starts pontificating about how
SYS/BSD/Linux this that or the other thing - often the idea came
elsewhere. Wide distribution and use was supplied by the XXX Channel but
there were many many fathers and mothers
To that end, someone once suggested to me that the inspiration for the
swapping implementation in early Unix came fro MTS, but I found that
dubious; the dates just don't line up.
- Dan C.
8:56 p.m.
On Tue, Jan 10, 2017 at 11:20 AM, Joerg Schilling <schily(a)schily.net> wrote:
Berny Goodheart <berny(a)berwynlodge.com> wrote:
[snip]
Surely Berny meant the file system switch here, which could have come from
early system V, but originated in research Unix (8th edition?). Note that
this list is very similar to that in the early part of his book on System V
internals.
- Dan C.
VFSSW <=== NO, this is
from SunOS-4
10:57 p.m.
Dan Cross <crossd(a)gmail.com> wrote:
On Tue, Jan 10, 2017 at 11:20 AM, Joerg Schilling
<schily(a)schily.net> wrote:
It is rather a part of the VFS interface that has first been completed with
SunOS-3.0 in late 1985.
There are small changes introduced into the VFS switch for SVr4 to permit to
mount special filesystems without the need of root permissions. They cause the
major differences between SunOS-4 and Svr4.
VFS uses two interface parts:
- the VFS switch with the vfs interface functions to mount a filesystem
and to stat it
- the VFS vnode interface with the vnode interface functions to hold the
interfaces like open(), mmap(), ...
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Berny Goodheart <berny(a)berwynlodge.com>
wrote:
[snip]
Surely Berny meant the file system switch here, which could have come from
early system V, but originated in research Unix (8th edition?). Note that
this list is very similar to that in the early part of his book on System V
internals. VFSSW <=== NO, this is
from SunOS-4
11:06 p.m.
On Wed, Jan 11, 2017 at 11:57:51PM +0100, Joerg Schilling wrote:
Dan Cross <crossd(a)gmail.com> wrote:
I think you are once again confused. System Vr3 had something called the
file system switch which is what Berny is talking about. SunOS had
virtual file system layer (VFS) and that would be one of things ported
to SVr4.
The history on wikipedia matches my memory and contradicts much of what
you've been claiming. For what it is worth, I didn't write a word of
that wikipedia page so others remember much as I do.
https://en.wikipedia.org/wiki/UNIX_System_V
On Tue, Jan 10, 2017 at 11:20 AM, Joerg Schilling
<schily(a)schily.net> wrote:
It is rather a part of the VFS interface that has first been completed with
SunOS-3.0 in late 1985. Berny Goodheart <berny(a)berwynlodge.com>
wrote:
[snip]
Surely Berny meant the file system switch here, which could have come from
early system V, but originated in research Unix (8th edition?). Note that
this list is very similar to that in the early part of his book on System V
internals. VFSSW <=== NO, this is
from SunOS-4
11:52 p.m.
Larry McVoy <lm(a)mcvoy.com> wrote:
But that SVr3 beast is not in Svr4.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
It is rather a
part of the VFS interface that has first been completed with
SunOS-3.0 in late 1985.
I think you are once again confused. System Vr3 had something called the
file system switch which is what Berny is talking about. SunOS had
virtual file system layer (VFS) and that would be one of things ported
to SVr4.
11:57 p.m.
On Thu, Jan 12, 2017 at 12:52:22AM +0100, Joerg Schilling wrote:
Larry McVoy <lm(a)mcvoy.com> wrote:
But that SVr3 beast is not in Svr4.
Correct, it got dumped in favor of the VFS layer from SunOS, which I
said already.
My point is that you were telling Berny that the FSS wasn't from
SV but it was.
You should go read that wikipedia page, so far as I can tell it's pretty
accurate and has a better version of the history that you do.
I suspect you've fallen victim to various people claiming stuff that
wasn't really accurate. Like Bill Joy being responsible for SVr4.
If by "responsible" you mean he worked on the code, I'm sure that's
not true. If by "responsible" you mean he talked to AT&T about it,
sure, that's pretty likely. You made it sound like the former which
just isn't plausible. For lots of reasons.
It is
rather a part of the VFS interface that has first been completed with
SunOS-3.0 in late 1985.
I think you are once again confused. System Vr3 had something called the
file system switch which is what Berny is talking about. SunOS had
virtual file system layer (VFS) and that would be one of things ported
to SVr4.
12 Jan
12 Jan
12:07 a.m.
Larry McVoy <lm(a)mcvoy.com> wrote:
Please refresh your memory and have a look at the sources...
The first of the two SunOS tables I am referring to is called "vfssw". I
thought this was what he referred to. I thought that he knows that what Svr3
used to have, did not make it into Svr4.
And BTW: Wikipedia is of low quality and unusable when something may be related
to religion. Check e.g. how long it took to name Konrad Zuse as the inventor of
the first usable computer. When I look at Wikipedia, I check whether the
references are trustworthy before I believe the claims.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
But that SVr3
beast is not in Svr4.
Correct, it got dumped in favor of the VFS layer from SunOS, which I
said already.
My point is that you were telling Berny that the FSS wasn't from
SV but it was.
1:58 a.m.
On Thu, Jan 12, 2017 at 01:07:17AM +0100, Joerg Schilling wrote:
Larry McVoy <lm(a)mcvoy.com> wrote:
Please refresh your memory and have a look at the sources...
So far you haven't mentioned a source base where I have not worked.
And you keep dropping names, which is fun, but I know all the names
you have dropped personally. John Pope came to my house after stopping
by at Matt Jacob's house. Matt was my neighbor in Noe Valley and he
was the guy who checked in my work on UFS (I was too chicken to do it,
I had been to some SunOS 4.x staff meetings where Gingell ripped people
a new asshole for doing something wrong. Matt checked in my UFS work
with the comment "this is the only thing we have that makes performance
better, it's going in".)
I don't know where you are getting your information from but the time
period you are talking about was when I was a pretty good engineer,
I lived in the Unix source code, mcvoy.com is internally known as
slovax, slovax was the 11/750 that had the 4.2 BSD source on it,
I spent a boatload of time reading that code. Kernel and userland.
Same for System III, same for the PWB release, same for System V,
I love this stuff. I'm a total nerd for this stuff, it's why I'm
on this list, the people I look up to are here.
I really wonder where you got your information from because it's a
little bit wrong.
--lm
But that
SVr3 beast is not in Svr4.
Correct, it got dumped in favor of the VFS layer from SunOS, which I
said already.
My point is that you were telling Berny that the FSS wasn't from
SV but it was.
10:39 a.m.
Larry McVoy <lm(a)mcvoy.com> wrote:
I really wonder where you got your information from
because it's a
little bit wrong.
Do you really believe I invented all these people? You already confirmed that
they exist. How do you believe, I could get the names without being in contact
with them?
I got my information from working on Solaris and in this special case, you seem
to forget that you definitely made a mistake. Maybe you now like to refresh
your memory....
From Solaris sys/vfs.h:
/*
* Filesystem type switch table.
*/
typedef struct vfssw {
char *vsw_name; /* type name -- max len _ST_FSTYPSZ */
int (*vsw_init) (int, char *);
/* init routine (for non-loadable fs only) */
int vsw_flag; /* flags */
mntopts_t vsw_optproto; /* mount options table prototype */
uint_t vsw_count; /* count of references */
kmutex_t vsw_lock; /* lock to protect vsw_count */
vfsops_t vsw_vfsops; /* filesystem operations vector */
} vfssw_t;
I however have to admit that I did also a mistake as struct vfssw just
contains the structure vfsops_t and is not the structure I had in mind itself.
But it is based on struct vfssw from SunOS-4 sys/vfs.h which looks this way:
/*
* Filesystem type switch table
*/
struct vfssw {
char *vsw_name; /* type name string */
struct vfsops *vsw_ops; /* filesystem operations vector */
};
It seems that "porting" it to Svr4 caused a dot to be appended to the
comment ;-)
BTW: in 1990 with SunOS-4.0, I could already modload my "wofs" as I added a few
nulled entries to the struct vfssw in os/vfs_conf.c, pretended that wofs was a
device driver and let it then install itself into one of the empty entries in
struct vfssw.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
3054
days inactive
3056
days old
26 comments
8 participants
participants (8)
-
arnold＠skeeve.com -
Berny Goodheart -
Chet Ramey -
Clem cole -
Dan Cross -
Larry McVoy -
schily＠schily.net -
Warner Losh