Re: [Xen-ia64-devel] [PATCH] initial cleanup of ivt.S - Al Stone - com.xensource.lists.xen-ia64-devel

5 messages in com.xensource.lists.xen-ia64-develRe: [Xen-ia64-devel] [PATCH] initial ...

From	Sent On	Attachments
Al Stone	10 Aug 2006 16:12	.patch
Tristan Gingold	11 Aug 2006 02:51
Al Stone	11 Aug 2006 07:26
Tristan Gingold	11 Aug 2006 07:46
Alex Williamson	14 Aug 2006 15:07

Subject:	Re: [Xen-ia64-devel] [PATCH] initial cleanup of ivt.S
From:	Al Stone (ah...@fc.hp.com)
Date:	08/11/2006 07:26:44 AM
List:	com.xensource.lists.xen-ia64-devel

On Fri, 2006-08-11 at 11:51 +0200, Tristan Gingold wrote:

Le Vendredi 11 Août 2006 01:12, Al Stone a écrit :

This patch reflects a patch I recently posted to the linux-ia64 mailing list to do essentially the same thing for ivt.S in upstream source.

I've reformatted the contents of the Xen version of ivt.S so that they are now readable on 80-column displays, in accordance with Linux coding standards. This is really just a first pass at cleaning up this code. In subsequent passes, I see several things need to be done:

1) Correct any additional typos or misspellings (there were quite a few cleaned up in this patch).

2) Make the formatting consistent (use the same style of comments everywhere, same syntax for stop bits,...).

3) Make sure the upstream and Xen ivt.S files are consistent where they need to be.

IMHO, ivt.S is too far from linux ivt.S A clean-up pass should be done: remove all #ifndef XEN code. But you reformatting work is also a good thing.

Just so I understand clearly -- the Xen ivt.S is for the hypervisor only, correct? I assume so, so I agree that the Xen version and Linux are -- and should be -- quite different. What I want to do is make sure we don't lose any improvements made in upstream; e.g., the syscall code had changed (and improved) quite a bit.

Which reminds me: there were some #if 0 blocks; do you think we still need or want any of those? Most of those looked like they could go away.

4) Do all of the TODOs in the file.

5) Handle the FIXMEs.

6) Go through an optimization pass.

In all of this patch, I only changed one line of assembly; there was a 'mov r31=pr;' in entry 23 (daccess_rights) that I changed to 'mov r31=pr;;' which is most likely what was meant. No other instructions were changed. Hopefully, I didn't harm any other white space formatting.

From what I read you could remove the ';;' stop bit.

Probably true. As I step through the instructions, I'll get rid of as many of the stop bits as I can (and I'll keep a special eye on this one :).

Thanks for the feedback.