Re: [announce][draft3] HVCS for inclusion in 2.6 tree

["Randy.Dunlap" <rddunlap@osdl.org>]

On Wed, 28 Jul 2004 11:39:29 -0500 Ryan Arnold wrote:

| > +int hvcs_convert(long to_convert)
| > +{
| > +	switch (to_convert) {
| > +		case H_Success:
| > +			return 0;
| > +		case H_Parameter:
| > +			return -EINVAL;
| > +		case H_Hardware:
| > +			return -EIO;
| > +		case H_Busy:
| > 
| > Can these H_values be converted from that coding style?
| 
| Converted to what/how?  I am confused by your question.
and:
| Randy, if you mean you'd like to see H_SUCCESS, H_PARAMETER, etc, I'd
| like to point out that all of the documentation I worked from uses the
| convention you see in my code.  Additionally, all of these hcall return
| codes already exist in include/asm-pp64/hvcall.h and have for some time.

OK, you made me look.  Most of that header file is reasonable except
for that set of #defines (IMO of course).
Being there doesn't mean that it was properly reviewed....
It can just mean that a merger/maintainer trusted whoever sent it
to them not to do undesirable things.

| > 
| > +		/* This is a very small struct and will be freed soon */
| > +		next_partner_info = kmalloc(sizeof(struct hvcs_partner_info),
| > +				GFP_ATOMIC);
| > 
| > Where is it freed?
| > 
| It is freed in hvcs_free_partner_info() because the partner info that is
| allocated needs to have scope outside of the hvcs_get_partner_info()
| call.

I see, thanks.

| > +#define __ALIGNED__	__attribute__((__aligned__(8)))
| > 
| > Why aligned? why 8?  (just curious)  Could use a comment if it's important.
| 
| Randy, here's an explanation given by Hollis Blanchard and Paul
| Mackerras that I'll add to the code as a comment.
| 
| The hcall interface involves putting 8 chars into each of two registers.
| We load up those 2 registers (in arch/ppc64/hvconsole.c) by casting
| char[16] to long[2].  It would work without __ALIGNED__, but a little
| (tiny) bit slower because an unaligned load is slower than aligned load.

Yes, thanks again.

--
~Randy