Re: [TUHS] the guy who brought up SVr4 on Sun machines

Larry McVoy <lm(a)mcvoy.com> wrote: You did not make a backup while you worked at Sun? Well, I am working in a governmental owned research unit and we did buy the SunOS-4.x sources for 100$ via the university access program. Before, I was working at H.Berthold AG, the first OEM customer for Sun equipment. Given that H.Berthold AG sold aprox. 25% of all Suns made in the 1980s, I had partial source access since 1986 and in 1988, I received a SunOS-4.0 kernel source tape from Bill Joy after the Sun Europe CEO asked him whether Bill could help me with with SunOS sources for my Dimploma thesis that is a Copy on Write filesystem for optical media (WOFS). While I cannot OSS this filesystem for SunOS-4.x, I am still planning to port it to OpenSolaris as this would permit me to OSS it. Hint: I have been told from Sun employees that the Sun ZFS group did read my diploma thesis before they started with ZFS even though it is written in German ;-) My dimploma thesis was also used as the VFS documentation for people who intended to write a new filesystem. But the SVr4 code has been created from modifying the SunOS-4.0 sources. BTW: AFAIK, Solaris 2 has been derived from SunOS-4.1.4 by adding the few parts of the SVr4 code that really differ from SunOS-4.x. There seems to be a general missunderstandings: I do not call SunOS-4.x a "BSD based OS" as SunOS-4.0 introduced a new memory management subsystem in the kernel. AT&T was very interested in this feature and because of this subsystem, the SVr4 kernel had to derived from the SunOS-4.0 kernel. This has been mentioned in talks on the Sun User group meeting in December 1987. I am not sure whether this was a talk from Bill Joy or from other people from the SunOS kernel group. The userland code from SVr4 however is fully derived from SVr3, ignoring all enhancements and fixes that appeared in BSD and SunOS before. What I have been told about why people believed that Solaris is slow was mainly caused by the fact that there was a "dd" based benchmark that did a lot 512 byte block transfers and since AT&T did not understand that an OS with virtual memory needs to use page aligned tranfser buffers, the AT&T "dd" until 1994 used "malloc()" instead of "valloc()" and this usually caused a 512 byte tansfer in "dd" to be split into two kernel transfers. 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/