It's working...It's working...nah, nah, nah, nah, nah, nah...
(hehehehehe)
I hadn't had a chance to work on it much, but was finally able to get the
first workable tests done yesterday. I'm still not happy with the code, so
it will probably be a bit yet.
Leland
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 ;-)
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
)
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
> 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
Right. And VM traps that call too.
> happens under VM when a guest attempts to write to the HMC. Does it get
> intercepted and rerouted to the
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 sev
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
>
> 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
>
> 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
lt;[EMAIL PROTECTED]>
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
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 sy
>
> 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
>
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 b
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.
So,
14 matches
Mail list logo