Porting Linux to IBM S/370
Moshe Bar
I have exclusive access to an elderly IBM 9370 which runs at the moment
VM/XA and VSE under it.
The machine is de-commissioned but I would like to use it to port Linux to
the S/370 architecture.
I have a C compiler as well as good S/370 assembler knowledge. AIX/370 runs
fine on this machine, by the way.
The machine has access to a 256kbit line to the net. Under VM/XA there are
many tools to facilitate the hosting of guest OSs and also to develop new
OSs.
I can do the assembler part of the kernel, but I need somebody who knows the
Linux boot procedure well. It seems to me that this is the most difficult
part of the port. I would also like to make my C compiler compile the GNU C
compiler, anybody with good knowledge of the GNU C source is welcome to
contribute.
I would very much like to shove Linux/390 into IBM's face.
Many thanks for any help
Moshe Bar
mb...@campofranco.com
Peter Samuelson
> I have exclusive access to an elderly IBM 9370 which runs at the moment
> VM/XA and VSE under it.
>
> The machine is de-commissioned but I would like to use it to port Linux to
> the S/370 architecture.
Wow, cool.
> I can do the assembler part of the kernel, but I need somebody who
> knows the Linux boot procedure well. It seems to me that this is the
> most difficult part of the port. I would also like to make my C
> compiler compile the GNU C compiler, anybody with good knowledge of
> the GNU C source is welcome to contribute.
Actually the boot procedure will not be the hard part of the port, and
furthermore for the boot stuff you need a '370 expert much more than a
Linux expert. I.e. it is not too hard, given existing Linux source, to
figure out what to do in what order (in the way of setting up page
tables, detecting hardware, setting up the interrupts, initializing the
console devices, etc.) but it *will* be a challenge to figure out how
to do all this on the '370 hardware, specifically.
The most difficult part is probably writing all the device drivers for
the hardware you have. This will be hard because probably little if
any of it is already written, and technical specs may or may not be
easy to come by.
Next most difficult may be getting gcc up to speed. Correction,
getting gcc *and* binutils up to speed (unless you can leverage your
current assembler and linker to some extent to cross-develop). The
debug-test cycle for binutils will be really annoying if you don't have
an OS to run your code on, since binutils produces binary-format files
that are really only machine-readable. (It may be easiest to port the
binutils to AIX/370 first then adapt them.) The debug-test cycle for
gcc is easier if you are as comfortable with the assembler as you say,
since at least the output there is text. Definitely you want to
recruit someone who has worked with the internals of gcc and libbfd
before, as the various spec files are utter gibberish to at least some
of us who haven't.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
Moshe Bar
>
>Actually the boot procedure will not be the hard part of the port, and
>furthermore for the boot stuff you need a '370 expert much more than a
>Linux expert. I.e. it is not too hard, given existing Linux source, to
>figure out what to do in what order (in the way of setting up page
>tables, detecting hardware, setting up the interrupts, initializing the
>console devices, etc.) but it *will* be a challenge to figure out how
>to do all this on the '370 hardware, specifically.
>
Well, I have been working as a System Engineer for the 370 architecture for
years, so I think I know how to let VM/XA bootstrap an OS personality. (VM
gives you excellent tools for that)
>The most difficult part is probably writing all the device drivers for
>the hardware you have. This will be hard because probably little if
>any of it is already written, and technical specs may or may not be
>easy to come by.
The devices are all pretty well documented and all conform to more or less
the same meta-specs. The problem seems rather how to write a driver for the
S/370 channels (the serial interface used on mainframes). I know how the
control words look like etc., but the addressing seems hard. For that I need
an ex-IBMer who worked on the MVS/XA implementation of the channels.
>
>Next most difficult may be getting gcc up to speed. Correction,
>getting gcc *and* binutils up to speed (unless you can leverage your
>current assembler and linker to some extent to cross-develop). The
>debug-test cycle for binutils will be really annoying if you don't have
>an OS to run your code on, since binutils produces binary-format files
>that are really only machine-readable. (It may be easiest to port the
>binutils to AIX/370 first then adapt them.)
Hmm, good idea, use AIX to test the binutils. Well, the AIX that I have is a
VERY old version (1993). But I can see what good it is. Wait....
... several hours later.....
Well, I got AIX under VM/XA up and tried compiling some difficult code I
wrote. Looked at the assembler. I think I might learn a thing or two there.
The debug-test cycle for
>gcc is easier if you are as comfortable with the assembler as you say,
>since at least the output there is text. Definitely you want to
>recruit someone who has worked with the internals of gcc and libbfd
>before, as the various spec files are utter gibberish to at least some
>of us who haven't.
Yeah, you're right. Well, if anybody knows gcc and libbfd, please send me an
email.
I will report here on my progress with the gcc port, if anybody wants to
know.
Thanks, Peter
Moshe Bar
>
>--
>Peter Samuelson
><sampo.creighton.edu!psamuels>
news.netvision.net.il
ut_user(it,loc), besides time.c?
Any info is welcome.
Many thanks
Moshe Bar
Peter Samuelson
> I started writing the assembler part of the port. I need to know who
> calls ut_user(it,loc), besides time.c?
I assume you meant put_user(), since ut_user() doesn't exist. If you
need to know where something is used or referenced in the Linux source
(or any other source), `grep' is your friend. (TAGS files are cool too
but I never get around to using them.) In any case, the command
find /usr/src/linux -name \*.c | xargs grep -l put_user
gives 243 filenames....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
Tor Arntsen
pe...@nemesis.niar.twsu.edu (Peter Samuelson) writes:
>I assume you meant put_user(), since ut_user() doesn't exist. If you
>need to know where something is used or referenced in the Linux source
>(or any other source), `grep' is your friend. (TAGS files are cool too
>but I never get around to using them.) In any case, the command
>
> find /usr/src/linux -name \*.c | xargs grep -l put_user
>
>gives 243 filenames....
I recommend 'idutils' for these kind of things. You can find
id-utils-3.2.tar.gz at your nearest GNU mirror. Then you can do
Once:
cd /usr/src/linux
mkid
This creates a file 'ID' in the current directory. It's a little database
of all interesting stuff in the directories from the current directory
and down.
And from then on:
cd /usr/src/linux/<whereever>
gid put_user
This will look up the symbol in the nearest ID file (looking in the
higher-up directories) and it will show you all the files w/line numbers
and relative paths from where you are with an exact match of put_user.
There's also an Emacs interface so you can do it from inside the
editor and get instant access to all the places where the function or
whatever is used.
I use it all the time, e.g. if I want to remove a non-used function
I can just do 'gid <function>' to find out if it is *really* unused.
Can't live without it.
It has a stupid bug though, on some file systems it is unable to find
the ID file unless it is less than 3 levels above you. But it works ok
most of the time.
- Tor
Pete Zaitcev
>> I started writing the assembler part of the port. I need to know who
>> calls ut_user(it,loc), besides time.c?
So, I take it you have working gcc or egcs? Otherwise assembler is pretty
pointless... One more suggestion: during the very initial phase of
sparc port we figured that it is much easier to compile across
hardware architectures than across operating environments. Many
kernel tools assume that you work on Linux, for example you need
bash for configure, gawk, etc. Get yourself a 486, compile there
and forget AIX, that would be my advice.
> find /usr/src/linux -name \*.c | xargs grep -l put_user
This is what I do:
find . \( -name 'Make*' -o -name '*.[chS]' \) -print > src.list.
We have more to it than C source. Keeping the list in a file saves
you time on subsequent greps: grep $(cat src.list|grep sparc).
--Pete
Paul Hughett
: TAGS files are cool too but I never get around to using them.
I have; they are well worth learning if you develop or support large
software projects. (Where the h*ll is put_time defined? Start emacs,
type m-. and enter the name of the function you want. Voila! Now your
only problem is figuring out the code itself.) They probably work as
well under vi, but I can't speak from personal experience there.
Paul Hughett
news.netvision.net.il
It is an interesting question. Should I port across OS or across the machine
itself?
Porting across OS in my case seems natural since I have a running 32bit C
compiler on AIX. But I see your point, too.
Before I invest a lot of time to do the wrong thing, I would like to get
some expert advice here.
If I try to compile th egcs compiler I get a lot more error messages form
the AIX C compiler, but they are more trivial. gcc seems more difficult to
get to run? Why is that?
On a side note, I also will have some problems with the 3270 terminals
emulating VT100s. AIX does that but it is proprietary code. Does anyone have
any ideas? The MVS/XA and VM/XA console themselves are very much like
VT100s. But not the other terminals. Additionally, the 3475 communication
controller really inisits on SNA. AIX also bypasses this problem somehow by
encapsulating TCP/IP in SNA. I guess I could also use the almost-open source
of LU6.2 to implement TCO/IP across IBM hardware.
Any ideas here?
I am now anyway, going ahead with the assembler parts of the port ie paging,
address translation etc.
Many thanks for all support.
Moshe Bar
Pete Zaitcev wrote in message ...
Richard Payne
>On a side note, I also will have some problems with the 3270 terminals
>emulating VT100s. AIX does that but it is proprietary code. Does anyone
have
>any ideas? The MVS/XA and VM/XA console themselves are very much like
>VT100s. But not the other terminals. Additionally, the 3475 communication
>controller really inisits on SNA. AIX also bypasses this problem somehow by
>encapsulating TCP/IP in SNA. I guess I could also use the almost-open
source
>of LU6.2 to implement TCO/IP across IBM hardware.
>
>Any ideas here?
While I don't know squat about a S/370, I came across this link a while ago,
SNA on Linux. Thought this might help you....
--
Rich Payne
(Speaking for myself, not my employer)
payner at timken dot com
Looking for Alpha-Linux info?
http://www.alphalinux.org
Moshe Bar
Moshe Bar>
bill davidsen
news.netvision.net.il <sc...@isdn.net.il> wrote:
| If I try to compile th egcs compiler I get a lot more error messages form
| the AIX C compiler, but they are more trivial. gcc seems more difficult to
| get to run? Why is that?
You can grab a working gcc from IBM's web site. Don't have the URL other
than on backup, but I found it without investing a day. If nothing else
you could try to build other compilers with that.
--
bill davidsen <davi...@tmr.com> CTO, TMR Associates, Inc
The young confuse living a long time with getting old,
the old confuse age with maturity.
Moshe Bar
AIX/370. It is quite old, but I tried compiling egcs and it doesn't look to
difficult to eventually make it work.
Now, once I have a valid egcs compiler, things might pick up speed
considerably.
Many thanks to everyone
Moshe Bar
Moshe Bar
Thanks for your help. Alas, the gcc you are referring is for the R/6000
architecture, which is PowerPC.
I am porting to S/370. I will continue to check if there is a gcc for this
architecture somewhere.
Moshe Bar
bill davidsen wrote in message
<72hs10$26fi$1...@newssvr03-int.news.prodigy.com>...
M Sweger
: >On a side note, I also will have some problems with the 3270 terminals
: >emulating VT100s. AIX does that but it is proprietary code. Does anyone
: have
: >any ideas? The MVS/XA and VM/XA console themselves are very much like
: >VT100s. But not the other terminals. Additionally, the 3475 communication
: >controller really inisits on SNA. AIX also bypasses this problem somehow by
: >encapsulating TCP/IP in SNA. I guess I could also use the almost-open
: source
: >of LU6.2 to implement TCO/IP across IBM hardware.
: >
: >Any ideas here?
: While I don't know squat about a S/370, I came across this link a while ago,
: SNA on Linux. Thought this might help you....
: --
: Rich Payne
: (Speaking for myself, not my employer)
: payner at timken dot com
: Looking for Alpha-Linux info?
: http://www.alphalinux.org
Wheres the link???
--
Mike,
mik...@whiterose.net
Mark Olsten
a VTAM style daemon on your Linux/370, that supports the 3174's,
3270's, 3745's, etc.
"news.netvision.net.il" <sc...@isdn.net.il> wrote:
>Thanks, Pete
>
>
>It is an interesting question. Should I port across OS or across the machine
>itself?
>
>Porting across OS in my case seems natural since I have a running 32bit C
>compiler on AIX. But I see your point, too.
>
>Before I invest a lot of time to do the wrong thing, I would like to get
>some expert advice here.
>
>If I try to compile th egcs compiler I get a lot more error messages form
>the AIX C compiler, but they are more trivial. gcc seems more difficult to
>get to run? Why is that?
>
>On a side note, I also will have some problems with the 3270 terminals
>emulating VT100s. AIX does that but it is proprietary code. Does anyone have
>any ideas? The MVS/XA and VM/XA console themselves are very much like
>VT100s. But not the other terminals. Additionally, the 3475 communication
>controller really inisits on SNA. AIX also bypasses this problem somehow by
>encapsulating TCP/IP in SNA. I guess I could also use the almost-open source
>of LU6.2 to implement TCO/IP across IBM hardware.
>
>Any ideas here?
>
David Grothe
> Maybe you are going about it in the wrong way. Maybe you should write
> a VTAM style daemon on your Linux/370, that supports the 3174's,
> 3270's, 3745's, etc.
Right. And contact Gcom for a good commercial SNA package for Linux to run them
:)
-- Dave
Stephen Lee - Post replies please
Moshe Bar <mb...@scii.net> wrote:
>Have some good news. Thanks to David Wasserstein, we do have a gcc for
>AIX/370. It is quite old, but I tried compiling egcs and it doesn't look to
>difficult to eventually make it work.
>
>Now, once I have a valid egcs compiler, things might pick up speed
>considerably.
>
>Many thanks to everyone
>
>Moshe Bar
But isn't gcc 2.7.x the preferred compiler for the kernel? I'd suggest
subscribing to linux-kernel too if you have not already done so.
Stephen
Peter Samuelson
[Moshe Bar <mb...@scii.net>]
> > Have some good news. Thanks to David Wasserstein, we do have a gcc
> > for AIX/370. It is quite old, but I tried compiling egcs and it
> > doesn't look to difficult to eventually make it work.
Compiling egcs for a supported target architecture should not be tough
-- it's writing the 370 target code that would be the hard part.
Assuming the gcc you dug up has source code available (which is
required by its license, so it had better) you should be able to hack
the support into egcs.
> > Now, once I have a valid egcs compiler, things might pick up speed
> > considerably.
[Stephen Lee]
> But isn't gcc 2.7.x the preferred compiler for the kernel?
Well, Linus reportedly uses it ... but if I were you I'd concentrate on
egcs, since that is the future of gcc, as far as we can see from here.
Also the source to egcs has been cleaned up some since it broke off gcc
(specifically the source directory structure was rearranged some).
The reason egcs is not supported particularly in 2.0.x-series kernels
is because of some buggy i386 assembly in the kernel. This has
absolutely no bearing on a new porting effort since all the assembly
has to be rewritten anyway.
> I'd suggest subscribing to linux-kernel too if you have not already
> done so.
Yeah, that might be worth while -- but it's a high-volume list so
expect to have to filter it unless you have a lot more time than I ever
have....
--
Peter Samuelson
<sampo.creighton.edu!psamuels>