From: Robin Holt <holt@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH 05/28] ia64/xen: import xen hypercall header file.
Date: Fri, 22 Feb 2008 06:32:20 +0000 [thread overview]
Message-ID: <20080222063220.GN11391@sgi.com> (raw)
In-Reply-To: <12036570471664-git-send-email-yamahata@valinux.co.jp>
On Fri, Feb 22, 2008 at 02:10:21PM +0900, Isaku Yamahata wrote:
I have no idea what the intent is for this patch, but I guess the end
result is merely some typedefs. It does appear to need some cleanups
> diff --git a/include/asm-ia64/xen/interface.h b/include/asm-ia64/xen/interface.h
> new file mode 100644
> index 0000000..69418f6
> --- /dev/null
> +++ b/include/asm-ia64/xen/interface.h
...
> +#ifndef __HYPERVISOR_IF_IA64_H__
> +#define __HYPERVISOR_IF_IA64_H__
Same old comment.
> +
> +/*
> + * TODO:
> + * linux's interface header removed XEN prefix
> + * Now just work around
> + */
> +#define DEFINE_GUEST_HANDLE_STRUCT(name) \
> + __DEFINE_XEN_GUEST_HANDLE(name, struct name)
> +#define DEFINE_GUEST_HANDLE(name) DEFINE_XEN_GUEST_HANDLE(name)
> +#define GUEST_HANDLE(name) XEN_GUEST_HANDLE(name)
> +
> +/* Structural guest handles introduced in 0x00030201. */
> +#if __XEN_INTERFACE_VERSION__ >= 0x00030201
Will this ever be false for the stuff in the kernel tree? if not, we
should clean this up before committing it.
> +#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
> + typedef struct { type *p; } __guest_handle_ ## name
> +#else
> +#define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
> + typedef type * __guest_handle_ ## name
> +#endif
> +
> +#define __DEFINE_XEN_GUEST_HANDLE(name, type) \
> + ___DEFINE_XEN_GUEST_HANDLE(name, type)
Assuming the above cleanup is valid, why have the __ and ___ variants?
> +#define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name)
> +#define XEN_GUEST_HANDLE(name) __guest_handle_ ## name
> +#define XEN_GUEST_HANDLE_64(name) XEN_GUEST_HANDLE(name)
By this point in the review, I am beginning to get the feeling that you
want any random group of characters that contain XEN, or GUEST to be a
valid group of characters. I am not asking you to change anything,
merely consider whether all of the defines are really needed. I don't
know and don't really want to know, but I do hope you take the time to
rethink the shear number of #defines that all come back to
___DEFINE_XEN_GUEST_HANDLE.
> +#define uint64_aligned_t uint64_t
> +#define set_xen_guest_handle(hnd, val) do { (hnd).p = val; } while (0)
> +#ifdef __XEN_TOOLS__
> +#define get_xen_guest_handle(val, hnd) do { val = (hnd).p; } while (0)
> +#endif
> +
> +#ifndef __ASSEMBLY__
> +/* Guest handles for primitive C types. */
> +__DEFINE_XEN_GUEST_HANDLE(uchar, unsigned char);
> +__DEFINE_XEN_GUEST_HANDLE(uint, unsigned int);
> +__DEFINE_XEN_GUEST_HANDLE(ulong, unsigned long);
> +__DEFINE_XEN_GUEST_HANDLE(u64, unsigned long);
> +DEFINE_XEN_GUEST_HANDLE(char);
> +DEFINE_XEN_GUEST_HANDLE(int);
> +DEFINE_XEN_GUEST_HANDLE(long);
> +DEFINE_XEN_GUEST_HANDLE(void);
> +
> +typedef unsigned long xen_pfn_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_pfn_t);
> +#define PRI_xen_pfn "lx"
> +#endif
> +
> +/* Arch specific VIRQs definition */
> +#define VIRQ_ITC VIRQ_ARCH_0 /* V. Virtual itc timer */
> +#define VIRQ_MCA_CMC VIRQ_ARCH_1 /* MCA cmc interrupt */
> +#define VIRQ_MCA_CPE VIRQ_ARCH_2 /* MCA cpe interrupt */
> +
> +/* Maximum number of virtual CPUs in multi-processor guests. */
> +/* WARNING: before changing this, check that shared_info fits on a page */
Just asking again, but can the above be turned into either a #error,
#warn, or a BUG_ON()?
> +#define MAX_VIRT_CPUS 64
> +
> +#ifndef __ASSEMBLY__
> +
> +typedef unsigned long xen_ulong_t;
> +
> +#ifdef __XEN_TOOLS__
> +#define XEN_PAGE_SIZE XC_PAGE_SIZE
> +#else
> +#define XEN_PAGE_SIZE PAGE_SIZE
> +#endif
> +
> +#define INVALID_MFN (~0UL)
> +
> +#define MEM_G (1UL << 30)
> +#define MEM_M (1UL << 20)
> +#define MEM_K (1UL << 10)
> +
> +/* Guest physical address of IO ports space. */
> +#define IO_PORTS_PADDR 0x00000ffffc000000UL
> +#define IO_PORTS_SIZE 0x0000000004000000UL
> +
> +#define MMIO_START (3 * MEM_G)
> +#define MMIO_SIZE (512 * MEM_M)
> +
> +#define VGA_IO_START 0xA0000UL
> +#define VGA_IO_SIZE 0x20000
> +
> +#define LEGACY_IO_START (MMIO_START + MMIO_SIZE)
> +#define LEGACY_IO_SIZE (64 * MEM_M)
> +
> +#define IO_PAGE_START (LEGACY_IO_START + LEGACY_IO_SIZE)
> +#define IO_PAGE_SIZE XEN_PAGE_SIZE
> +
> +#define STORE_PAGE_START (IO_PAGE_START + IO_PAGE_SIZE)
> +#define STORE_PAGE_SIZE XEN_PAGE_SIZE
> +
> +#define BUFFER_IO_PAGE_START (STORE_PAGE_START + STORE_PAGE_SIZE)
> +#define BUFFER_IO_PAGE_SIZE XEN_PAGE_SIZE
> +
> +#define BUFFER_PIO_PAGE_START (BUFFER_IO_PAGE_START + BUFFER_IO_PAGE_SIZE)
> +#define BUFFER_PIO_PAGE_SIZE XEN_PAGE_SIZE
> +
> +#define IO_SAPIC_START 0xfec00000UL
> +#define IO_SAPIC_SIZE 0x100000
> +
> +#define PIB_START 0xfee00000UL
> +#define PIB_SIZE 0x200000
> +
> +#define GFW_START (4 * MEM_G - 16 * MEM_M)
> +#define GFW_SIZE (16 * MEM_M)
> +
> +/* Nvram belongs to GFW memory space */
> +#define NVRAM_SIZE (MEM_K * 64)
> +#define NVRAM_START (GFW_START + 10 * MEM_M)
> +
> +#define NVRAM_VALID_SIG 0x4650494e45584948 /* "HIXENIPF" */
> +struct nvram_save_addr {
> + unsigned long addr;
> + unsigned long signature;
> +};
> +
> +struct pt_fpreg {
> + union {
> + unsigned long bits[2];
> + long double __dummy; /* force 16-byte alignment */
> + } u;
> +};
> +
> +union vac {
> + unsigned long value;
> + struct {
> + int a_int:1;
> + int a_from_int_cr:1;
> + int a_to_int_cr:1;
> + int a_from_psr:1;
> + int a_from_cpuid:1;
> + int a_cover:1;
> + int a_bsw:1;
> + long reserved:57;
> + };
> +};
> +typedef union vac vac_t;
I thought typedefs were frowned upon.
I only skimmed the remainder of the file. More of the same comments you
have seen before.
> +/* xen perfmon */
> +#ifdef XEN
> +#ifndef __ASSEMBLY__
> +#ifndef _ASM_IA64_PERFMON_H
> +
> +#include <xen/list.h> /* asm/perfmon.h requires struct list_head */
> +#include <asm/perfmon.h>
Why not just always include these two. They should be doing their own
#ifndef's to prevent reinclusion. If not, correct them.
Thanks,
Robin
next prev parent reply other threads:[~2008-02-22 6:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-22 5:10 [PATCH 05/28] ia64/xen: import xen hypercall header file Isaku Yamahata
2008-02-22 6:32 ` Robin Holt [this message]
[not found] <20080221091731.641745000@ls.local.valinux.co.jp>
2008-02-21 9:17 ` yamahata
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080222063220.GN11391@sgi.com \
--to=holt@sgi.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.