[TUHS] While on the subject of 32V ...

[TUHS] While on the subject of 32V ...

[Pat Villani]

Folks,

I recently copied down the 32V source, and compiled the kernel with gcc.  Much 
to my surprise, most of it compiled.  I then split out the machine dependent 
versus the machine independent files (loose classification :-), and compiled 
again.  Naturally, in both cases, you could not actually build a kernel because 
there are vax specific .s files, but the individual C files compiled.  Not a bad 
start.

As a result, I've been giving serious consideration to porting it to Intel IA32 
platforms.  It's much simpler than the unix I worked on until last year (Tru64, 
aka OSF/1 and Digital UNIX), and the 32V kernel is only a little bigger than the 
original FreeDOS kernel I wrote.  The Caldera license is pretty much a BSD 
license, which could be considered an open source license.  This means I should 
be able to work on it without worrying about IP, although I'd still need 
management approval.

Should I undertake such an project, would there be enough interest to justify 
the effort?

Pat

-- 
You can't build a reputation on what you are going to do. -- Henry Ford

[TUHS] While on the subject of 32V ...

[Wesley Parish]

I tried the same with a few of the utilities and a make with the kernel files.

<shock and awe>Dependencies again</shock and awe> - with most of the utilities 
the compile was easy, since their dependencies were easily filled by the 
standard Linux C libraries.  Since many of the kernel dependencies depend on 
the vax specific .s files and I don't know anything about the vax at the 
moment, I decided to leave it until I _did_ know.  That's why I've been 
asking stoopid questions on this list.

Well, if you're keen on it, I am too.  I need something to do over the 
holidays.

Wesley Parish

On Tue, 21 Oct 2003 02:35, Pat Villani wrote:
> Folks,
>
> I recently copied down the 32V source, and compiled the kernel with gcc. 
> Much to my surprise, most of it compiled.  I then split out the machine
> dependent versus the machine independent files (loose classification :-),
> and compiled again.  Naturally, in both cases, you could not actually build
> a kernel because there are vax specific .s files, but the individual C
> files compiled.  Not a bad start.
>
> As a result, I've been giving serious consideration to porting it to Intel
> IA32 platforms.  It's much simpler than the unix I worked on until last
> year (Tru64, aka OSF/1 and Digital UNIX), and the 32V kernel is only a
> little bigger than the original FreeDOS kernel I wrote.  The Caldera
> license is pretty much a BSD license, which could be considered an open
> source license.  This means I should be able to work on it without worrying
> about IP, although I'd still need management approval.
>
> Should I undertake such an project, would there be enough interest to
> justify the effort?
>
> Pat

-- 
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."

[TUHS] While on the subject of 32V ...

[Pat Villani]

Wesley Parish wrote:
> I tried the same with a few of the utilities and a make with the kernel files.

Having come to HP from DEC by way of Compaq, vax isn't that challenging 
for me.  :)

I did not try compiling the utilities.  My interests have always been at 
the kernel level.  I am encouraged by the fact that you were able to 
build the utilities.  This should make life a lot easier.

What I've done so far is split the files into vax specific and "somewhat 
vax specific" platform neutral files.  This is just a first cut, where I 
separated out things such as .s files and .c files that are vax 
dependent, such as device drivers, from files that should be platform 
neutral.

I did not go through the platform neutral files to correct for vax 
dependencies, if any.  That's my next task.

I'll tar up what I have so far and put it on a web site for folks to 
look at.

Pat

[TUHS] While on the subject of 32V ...

[Wesley Parish]

I'm doing an en-masse compile of the programs in the /32V/usr/src/cmd 
directory, little-by-little, bit-by-bit.

Some don't compile, some do.

I've also run the bigger utilities - in their separate directories - through 
make with Greg Lehey's little one-liner script from "Porting UNIX Software", 
pg 74:
make 2>&1 | tee -a Make.log 

and will gzip and email them to you if you like.

Wesley Parish

On Wed, 22 Oct 2003 03:00, Pat Villani wrote:
> Wesley Parish wrote:
> > I tried the same with a few of the utilities and a make with the kernel
> > files.
>
> Having come to HP from DEC by way of Compaq, vax isn't that challenging
> for me.  :)
>
> I did not try compiling the utilities.  My interests have always been at
> the kernel level.  I am encouraged by the fact that you were able to
> build the utilities.  This should make life a lot easier.
>
> What I've done so far is split the files into vax specific and "somewhat
> vax specific" platform neutral files.  This is just a first cut, where I
> separated out things such as .s files and .c files that are vax
> dependent, such as device drivers, from files that should be platform
> neutral.
>
> I did not go through the platform neutral files to correct for vax
> dependencies, if any.  That's my next task.
>
> I'll tar up what I have so far and put it on a web site for folks to
> look at.
>
> Pat

-- 
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."

[TUHS] While on the subject of 32V ...

[Pat Villani]

OK.  I'm in the process of getting approval for this project.  I'll put 
what I've done so far up on a web site and send out the URL.  If you do 
send the gzip'ed commands, I'll include those as well.  No rush, as I 
won't do any of this until this weekend.

Pat

Wesley Parish wrote:
> I'm doing an en-masse compile of the programs in the /32V/usr/src/cmd 
> directory, little-by-little, bit-by-bit.
> 
> Some don't compile, some do.
> 
> I've also run the bigger utilities - in their separate directories - through 
> make with Greg Lehey's little one-liner script from "Porting UNIX Software", 
> pg 74:
> make 2>&1 | tee -a Make.log 
> 
> and will gzip and email them to you if you like.
> 
> Wesley Parish
> 
> On Wed, 22 Oct 2003 03:00, Pat Villani wrote:
> 
>>Wesley Parish wrote:
>>
>>>I tried the same with a few of the utilities and a make with the kernel
>>>files.
>>
>>Having come to HP from DEC by way of Compaq, vax isn't that challenging
>>for me.  :)
>>
>>I did not try compiling the utilities.  My interests have always been at
>>the kernel level.  I am encouraged by the fact that you were able to
>>build the utilities.  This should make life a lot easier.
>>
>>What I've done so far is split the files into vax specific and "somewhat
>>vax specific" platform neutral files.  This is just a first cut, where I
>>separated out things such as .s files and .c files that are vax
>>dependent, such as device drivers, from files that should be platform
>>neutral.
>>
>>I did not go through the platform neutral files to correct for vax
>>dependencies, if any.  That's my next task.
>>
>>I'll tar up what I have so far and put it on a web site for folks to
>>look at.
>>
>>Pat
> 
> 

[TUHS] While on the subject of 32V ...

[Wesley Parish]

Just a short note to say I've compiled the libF77.a library archive.

I'll try the rest of the libraries, and note which ones compile cleanly and 
which throw their hands up in horror.

Wesley Parish

On Sat, 25 Oct 2003 02:41, Pat Villani wrote:
> OK.  I'm in the process of getting approval for this project.  I'll put
> what I've done so far up on a web site and send out the URL.  If you do
> send the gzip'ed commands, I'll include those as well.  No rush, as I
> won't do any of this until this weekend.
>
> Pat
>
> Wesley Parish wrote:
> > I'm doing an en-masse compile of the programs in the /32V/usr/src/cmd
> > directory, little-by-little, bit-by-bit.
> >
> > Some don't compile, some do.
> >
> > I've also run the bigger utilities - in their separate directories -
> > through make with Greg Lehey's little one-liner script from "Porting UNIX
> > Software", pg 74:
> > make 2>&1 | tee -a Make.log
> >
> > and will gzip and email them to you if you like.
> >
> > Wesley Parish
> >
> > On Wed, 22 Oct 2003 03:00, Pat Villani wrote:
> >>Wesley Parish wrote:
> >>>I tried the same with a few of the utilities and a make with the kernel
> >>>files.
> >>
> >>Having come to HP from DEC by way of Compaq, vax isn't that challenging
> >>for me.  :)
> >>
> >>I did not try compiling the utilities.  My interests have always been at
> >>the kernel level.  I am encouraged by the fact that you were able to
> >>build the utilities.  This should make life a lot easier.
> >>
> >>What I've done so far is split the files into vax specific and "somewhat
> >>vax specific" platform neutral files.  This is just a first cut, where I
> >>separated out things such as .s files and .c files that are vax
> >>dependent, such as device drivers, from files that should be platform
> >>neutral.
> >>
> >>I did not go through the platform neutral files to correct for vax
> >>dependencies, if any.  That's my next task.
> >>
> >>I'll tar up what I have so far and put it on a web site for folks to
> >>look at.
> >>
> >>Pat

-- 
Clinesterton Beademung - in all of love.
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Pat Villani]

I got corporate approval, well, as best as I could from corporate legal, 
to proceed.  The only caveats are: beware of the SCO shenanigans as 32V 
may encounter a similar wrath, and make sure I don't "compete" with HP. 
  How in the world a 15 year old operating system threatens SCO or 
competes with HP is beyond me.  At any rate, I'll start moving the email 
activity off the corporate network soon, in order to comply with open 
source participation rules.

In the meantime, I have just placed a copy of the reorganized kernel 
files in ftp://server.opensourcedepot.com/pub/32V. This is my personal 
server, so it's easy for me to put source code there, at least for now. 
  The reorganization consists mainly of separating out drivers, and a 
scratch file for a locore.asm file.  I also placed formalized license 
notices in the directory and files, so to alert everyone of the license 
terms.

It's a start ...

Pat

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Wesley Parish]

It's downloaded.

I would suggest renaming it to something like 32V-x86, though - makes it 
easier to remember it's not going to be precisely the same as 32V for VAX.

In relation to corporate caveats, the only way you could actually compete with 
HP is if somehow, in a matter of months, you redid the entire development of 
BSD and SVRx, up to the stage HP-UX currently is at.

Oh well, time for me to brush off my Pajari book on Unix device drivers and 
see if I can make the grade! ;)

Wesley Parish


On Fri, 31 Oct 2003 01:56, Pat Villani wrote:
> I got corporate approval, well, as best as I could from corporate legal,
> to proceed.  The only caveats are: beware of the SCO shenanigans as 32V
> may encounter a similar wrath, and make sure I don't "compete" with HP.
>   How in the world a 15 year old operating system threatens SCO or
> competes with HP is beyond me.  At any rate, I'll start moving the email
> activity off the corporate network soon, in order to comply with open
> source participation rules.
>
> In the meantime, I have just placed a copy of the reorganized kernel
> files in ftp://server.opensourcedepot.com/pub/32V. This is my personal
> server, so it's easy for me to put source code there, at least for now.
>   The reorganization consists mainly of separating out drivers, and a
> scratch file for a locore.asm file.  I also placed formalized license
> notices in the directory and files, so to alert everyone of the license
> terms.
>
> It's a start ...
>
> Pat
>
>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
Clinesterton Beademung - in all of love.
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Pat Villani]

Silly lawyers :-)  I know I'm good, but building in all the HP-UX 
features in a few months?  Not that good (or modest for that matter).

Hm, 32V-x86 huh?  Maybe, but I'd like to make it fairly portable and 
have a number of targets built from the same source tree.  I don't know 
if that will ever happen, but I don't want to design it out either by 
name or file partitioning.  Maybe we can address the project name at a 
later date.

I'll keep the VAX port alive throughout the project by making sure I can 
cross compile a clean VAX kernel at every milestone.  There may still be 
a VAX in the building somewhere.  Even if one was around, I won't be 
testing the VAX port thanks to HP legal.  We're now cleaning house of 
alpha systems, so a VAX is almost impossible to locate.  Darn mergers 
keeps wiping them out, like that asteroid and dinosaurs years ago ;-)

Progress: I'm working on the make file.  I'm trying to get a clean build 
by substituting stubs for the VAX code I ripped out.  Once done, I can 
concentrate on x86 equivalents.

Device drivers: I have keyboard and character cell VGA code I can use. 
I had been planning on adapting the Hale Landis ATA code from 
http://www.ata-atapi.com/, and the Thix floppy driver from 
http://www.hulubei.net/tudor/thix/ is probably a good piece of code to 
model the 32V driver on.

Pat

Wesley Parish wrote:

> It's downloaded.
> 
> I would suggest renaming it to something like 32V-x86, though - makes it 
> easier to remember it's not going to be precisely the same as 32V for VAX.
> 
> In relation to corporate caveats, the only way you could actually compete with 
> HP is if somehow, in a matter of months, you redid the entire development of 
> BSD and SVRx, up to the stage HP-UX currently is at.
> 
> Oh well, time for me to brush off my Pajari book on Unix device drivers and 
> see if I can make the grade! ;)
> 
> Wesley Parish

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Wesley Parish]

Just an update - I'm now compiling ~/[...]/32V/usr/src/libc/gen to *.o using 
gcc set with -I../../include .  Most of them compile smoothly.

I hope I'll have most of the library compiled to *.o soon, enough for using as 
the basis for compiling the utilities to 32I.

Wesley Parish

-- 
Clinesterton Beademung - in all of love.
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Pat Villani]

Good progress.  I'll probably use a linux like system call mechanism, so 
expect an inline function for the system calls.

Pat

Wesley Parish wrote:

> Just an update - I'm now compiling ~/[...]/32V/usr/src/libc/gen to *.o using 
> gcc set with -I../../include .  Most of them compile smoothly.
> 
> I hope I'll have most of the library compiled to *.o soon, enough for using as 
> the basis for compiling the utilities to 32I.
> 
> Wesley Parish
> 

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Wesley Parish]

I'm trying to work out whether or not gcc takes a look at its own header files 
before or after it looks at the ones I've set it to look at - I got some 
weird warnings and error messages before I expanded the -I to 

gcc -I./../../include -I./../../include/sys -I./../sys/h

Still need the *.s files in the libraries dealt with, and as before, I know 
nothing of the VAX assembler syntax and mostly x86 in Intel syntax.

If anyone wants to join in with this, I would be very, very grateful.

Wesley Parish

P.S.  I've got to redo the utilities - I think that once I get the libraries 
sorted out, the utilities will be easy meat.

On Tue, 04 Nov 2003 04:34, Pat Villani wrote:
> Good progress.  I'll probably use a linux like system call mechanism, so
> expect an inline function for the system calls.
>
> Pat
>
> Wesley Parish wrote:
> > Just an update - I'm now compiling ~/[...]/32V/usr/src/libc/gen to *.o
> > using gcc set with -I../../include .  Most of them compile smoothly.
> >
> > I hope I'll have most of the library compiled to *.o soon, enough for
> > using as the basis for compiling the utilities to 32I.
> >
> > Wesley Parish

-- 
Clinesterton Beademung - in all of love.
Mau e ki, "He aha te mea nui?"
You ask, "What is the most important thing?"
Maku e ki, "He tangata, he tangata, he tangata."
I reply, "It is people, it is people, it is people."

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Pat Villani]

For what you're doing, I think you'll want to add -nostdinc, and 
-nodefaultlibs to your gcc command line.  The -nostdinc option stops the 
compiler from looking at the standard include path files, and the 
-nodefaultlibs option causes the compiler to not use any of the gcc 
libraries while still using the standard startup file.  You'll have to 
supply the paths to the headers and libraries yourself.

In case I'm wrong, and you need to supply your own startup code as well, 
change the -nodefaultlibs option to -nostdlib.  That drops all standard 
startup code and libraries from the build.  It's the set of options I'm 
using in the current kernel build (to be released next week some time).

According to the gcc docs, the compiler may generate calls to memcmp, 
memset, and memcpy.  That means they'll be the first calls you'll have 
to implement in your libraries.

Pat

Wesley Parish wrote:
> I'm trying to work out whether or not gcc takes a look at its own header files 
> before or after it looks at the ones I've set it to look at - I got some 
> weird warnings and error messages before I expanded the -I to 
> 
> gcc -I./../../include -I./../../include/sys -I./../sys/h
> 
> Still need the *.s files in the libraries dealt with, and as before, I know 
> nothing of the VAX assembler syntax and mostly x86 in Intel syntax.
> 
> If anyone wants to join in with this, I would be very, very grateful.
> 
> Wesley Parish
> 
> P.S.  I've got to redo the utilities - I think that once I get the libraries 
> sorted out, the utilities will be easy meat.
> 
> On Tue, 04 Nov 2003 04:34, Pat Villani wrote:
> 
>>Good progress.  I'll probably use a linux like system call mechanism, so
>>expect an inline function for the system calls.
>>
>>Pat
>>
>>Wesley Parish wrote:
>>
>>>Just an update - I'm now compiling ~/[...]/32V/usr/src/libc/gen to *.o
>>>using gcc set with -I../../include .  Most of them compile smoothly.
>>>
>>>I hope I'll have most of the library compiled to *.o soon, enough for
>>>using as the basis for compiling the utilities to 32I.
>>>
>>>Wesley Parish
> 
> 

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Greg Lehey]

On Thursday, 30 October 2003 at  7:56:41 -0500, Pat Villani wrote:
> I got corporate approval, well, as best as I could from corporate legal,
> to proceed.  The only caveats are: beware of the SCO shenanigans as 32V
> may encounter a similar wrath,

I'm only just catching up with this thread, but I'm surprised that
nobody else pointed out that SCO is the same company that released
"ancient UNIX" under a free license in January 2002.  Given SCO's
behaviour, that doesn't guarantee that they won't cause problems, but
it should severely limit the scope.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers

32V update (was Re: [TUHS] While on the subject of 32V ...)

[Pat Villani]

I have my opinions about SCO, and what they're doing.  I don't think 
we'll see any problems because this activity is down in the noise.  They 
need to challenge Linux at the enterprise level.  It will be quite some 
time, if ever, that 32V reaches that level of complexity in order to be 
a threat.

For now, it's an exercise in nostalgia.  In 1980, a friend and I 
investigated licensing unix for sale on 68K and 8086 based computers. 
We couldn't raise the $68,000 source+binary license fee, so the project 
died.  That was more than double my salary as an engineer at that time.

Now, 23 years later, I'm going to do a port to see how close my original 
estimates are to reality.  After the initial port, who knows?

Pat

Greg Lehey wrote:

> On Thursday, 30 October 2003 at  7:56:41 -0500, Pat Villani wrote:
> 
>>I got corporate approval, well, as best as I could from corporate legal,
>>to proceed.  The only caveats are: beware of the SCO shenanigans as 32V
>>may encounter a similar wrath,
> 
> 
> I'm only just catching up with this thread, but I'm surprised that
> nobody else pointed out that SCO is the same company that released
> "ancient UNIX" under a free license in January 2002.  Given SCO's
> behaviour, that doesn't guarantee that they won't cause problems, but
> it should severely limit the scope.
> 
> Greg
> --
> Finger grog at lemis.com for PGP public key
> See complete headers for address and phone numbers
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> 

[TUHS] While on the subject of 32V ...

[David Presotto]

Arnold forwraded this to me:

> Date: Mon, 20 Oct 2003 09:35:40 -0400
> From: Pat Villani <Pat.Villani at hp.com>
> To: tuhs at tuhs.org
> Subject: [TUHS] While on the subject of 32V ...
>
> Folks,
>
> I recently copied down the 32V source, and compiled the kernel with gcc.  Much 
> to my surprise, most of it compiled.  I then split out the machine dependent 
> versus the machine independent files (loose classification :-), and compiled 
> again.  Naturally, in both cases, you could not actually build a kernel because 
> there are vax specific .s files, but the individual C files compiled.  Not a bad 
> start.
>
> As a result, I've been giving serious consideration to porting it to Intel IA32 
> platforms.  It's much simpler than the unix I worked on until last year (Tru64, 
> aka OSF/1 and Digital UNIX), and the 32V kernel is only a little bigger than the 
> original FreeDOS kernel I wrote.  The Caldera license is pretty much a BSD 
> license, which could be considered an open source license.  This means I should 
> be able to work on it without worrying about IP, although I'd still need 
> management approval.
>
> Should I undertake such an project, would there be enough interest to justify 
> the effort?
>
> Pat
>
> -- 
> You can't build a reputation on what you are going to do. -- Henry Ford

He noted the following and asked if I'ld like it posted to this list:

	I see from subsequent mail that a project has been started.

	The members of this list seem to share some common characteristics:

	1. Some spare time for working with code.

	2. A willingness to hack on code.

	3. A desire to work with cleaner, smaller simpler versions of Unix,
	   instead of the modern, er, *full featured* open source systems
 	  (Linux, *BSD).

	I'd like to suggest that perhaps members of this list should check out
	Plan 9 From Bell Labs (http://plan9.bell-labs.com).  The Plan 9 developers
	have recently posted a request for help, for people to tackle some projects
	that need tackling.  Why should people here look at it?

	1. It's from Bell Labs: quality design and concepts guaranteed. (:-)

	2. It's an opportunity to move into the future, instead of hiding out
	   in the past.

	3. Plan 9 deserves good help.

	4. People who appreciate early Unix and current Plan 9 will be welcomed
	   warmly.

	So, check it out,

We sure would like more people using our system and our license is OSI
approved so it least has one stamp as open source.  It clearly is not as
simple 32V or our 10th edition unix.  However, it comes close and is way
simpler than either Linux or the current BSDs.

[TUHS] While on the subject of 32V ...

[Steve Nickolas]

>From: Pat Villani <Pat.Villani at hp.com>
>Sent: Mon, 20 Oct 2003 09:35:40 -0400
>To: tuhs at tuhs.org
>Subject: [TUHS] While on the subject of 32V ...

>Folks,

>I recently copied down the 32V source, and compiled the kernel with
>gcc. \x01Much to my surprise, most of it compiled. \x01I then split out the
>machine dependent versus the machine independent files (loose
>classification :-), and compiled again. \x01Naturally, in both cases, you
>could not actually build a kernel because there are vax specific .s
>files, but the individual C files compiled. \x01Not a bad start.
Whew.  Goes to show something about GCC backward compatibility.

>As a result, I've been giving serious consideration to porting it to
>Intel IA32 platforms. \x01It's much simpler than the unix I worked on
>until last year (Tru64, aka OSF/1 and Digital UNIX), and the 32V
>kernel is only a little bigger than the original FreeDOS kernel I
>wrote. \x01The Caldera license is pretty much a BSD license, which could
>be considered an open source license. \x01This means I should be able to
>work on it without worrying about IP, although I'd still need 
>management approval.

It's basically the old (with advertising) BSD license, AFAICT.

>Should I undertake such an project, would there be enough interest to
>justify the effort?

I for one would be interested... :)

>Pat

-uso.

[TUHS] While on the subject of 32V ...

[Phil Garcia]

> <snip>
> I've been giving serious consideration to porting it to
> Intel IA32 platforms.  It's much simpler than the unix I worked on
> until last year (Tru64, aka OSF/1 and Digital UNIX), and the 32V
> kernel is only a little bigger than the original FreeDOS kernel I
> wrote.  The Caldera license is pretty much a BSD license, which
> could be considered an open source license.  This means I should be
> able to work on it without worrying about IP, although I'd still
> need management approval.  Should I undertake such an project, would
> there be enough interest to justify the effort?

I'd certainly be intrigued enough to run it.