Lucius, Leland wrote:
That might be too short though as it wouldn't be easy to remember. Then I
thought, use the full 8 characters of the zipl.conf section name, but that
seemd like a waste. So, you're suggestion of 4 might very well be a good
middle of the road.
From the way other operating
]
To: [EMAIL PROTECTED]
Subject: Re: Suggestions on how to implement LOADPARM
Date: Sun, 9 Mar 2003 14:45:31 -0600
I guess what you should do is support a number of IPL
sections identified
by something of 4 bytes, say a number of 'slots' in the IPL
record. Either
learn zipl how to put things
I find the entire zipl.conf thing very unpleasant in how it
handles overrides
of the values in the config file. Would you want to rewrite
all these entries
each time you update one kernel, or what? I suppose there is
an advantage if
you make sure that all entries are still pointing to
Why not implement this somewhat like lilo does this. One
could simply put
out a prompt on the hmc, and if no response is given within a
certain amount
of time then simply continue (as lilo does).
It's possible as the same interface used to get the LOADPARM can be used to
send/receive info
On Monday, 03/10/2003 at 11:14 CST, Lucius, Leland
[EMAIL PROTECTED] wrote:
It's possible as the same interface used to get the LOADPARM can be used
to
send/receive info to the HMC. Something that I'm not clear on is what
happens under VM when a guest attempts to write to the HMC. Does it get
What I had in mind was to hand off the handling of LOADPARM to
the kernel parm string processing: append a loadparm= token
to the parm string, with or without the VM IPL PARM appendage.
(That is, PARM (VM only) and LOADPARM (VM also) would
operate independently of each other.)
This does
)
when running under VM.
Jan Jaeger.
From: Alan Altmark [EMAIL PROTECTED]
Reply-To: Linux on 390 Port [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Suggestions on how to implement LOADPARM
Date: Mon, 10 Mar 2003 12:23:14 -0500
When a VM guest attempts to talk to the integrated HMC console
On Monday, 03/10/2003 at 06:50 GMT, Jan Jaeger [EMAIL PROTECTED]
wrote:
#CP uppercasing the response on VINPUT is inconsistent with real
machine
behaviour. What I would prefer, is a TERM MODE SYSCONS setting in VM.
This
such that operation under VM using the syscons interface becomes more
Lucius, Leland wrote:
Well, I reckon that is true. But, there are sufficient examples available
to get it to work. A lot of tracing under VM really helped out too. (Did I
mention that VM is AWESOME?)
Don't know, but go figure: I'm pretty sure there is a lot more where the VM
trace came from
I guess what you should do is support a number of IPL
sections identified
by something of 4 bytes, say a number of 'slots' in the IPL
record. Either
learn zipl how to put things in these slots, or use a
separate userspace
program that can copy the first entry (written by zipl) to
one of
I've got my own ideas and needs, but they're probably kinda shortsighted for
everyone else as they are simple.
Modding zipl will be no fun task (well, at least zipl.c anyway...common.S
was quite fun and is ready to go) so I thought I'd get suggestions up front
and not have to redo for anyone.
Lucius, Leland wrote:
Modding zipl will be no fun task (well, at least zipl.c anyway...common.S
was quite fun and is ready to go) so I thought I'd get suggestions up front
and not have to redo for anyone.
I guess what you should do is support a number of IPL sections identified
by something of 4
12 matches
Mail list logo
