From: Christoph Hellwig <hch@infradead.org>
To: Roland Dreier <rolandd@cisco.com>
Cc: linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [PATCH 01/13] [RFC] ipath basic headers
Date: Sat, 17 Dec 2005 13:14:56 +0000 [thread overview]
Message-ID: <20051217131456.GA13043@infradead.org> (raw)
In-Reply-To: <200512161548.aLjaDpGm5aqk0k0p@cisco.com>
> + * $Id: ipath_common.h 4491 2005-12-15 22:20:31Z rjwalsh $
please remove RCSIDs everywhere.
> +#ifdef __KERNEL__
> +#include <linux/ioctl.h>
> +#include <linux/uio.h>
> +#include <asm/atomic.h>
> +#else /* !__KERNEL__; user mode */
> +#include <sys/ioctl.h>
> +#include <sys/uio.h>
> +#include <sys/types.h>
> +#include <stdint.h>
> +
> +/* these aren't implemented for user mode, which is OK until we multi-thread */
> +typedef struct _atomic {
> + uint32_t counter;
> +} atomic_t; /* no atomic_t type in user-land */
> +#define atomic_set(a,v) ((a)->counter = (v))
> +#define atomic_inc_return(a) (++(a)->counter)
> +#define likely(x) (x)
> +#define unlikely(x) (x)
> +
> +#define yield() sched_yield()
Please push this out. It's fine if they reuse kernel-code in userspace
this way, but please move the compat wrappers to a separate file that's
not in the kernel tree.
> +typedef uint8_t ipath_type;
totally meaningless typedef
> +#ifndef _BITS_PER_BYTE
> +#define _BITS_PER_BYTE 8
> +#endif
WTF?
> +
> +static __inline__ void ipath_shortcopy(void *dest, void *src, uint32_t cnt)
> + __attribute__ ((always_inline));
> +/*
> + * this is used for very short copies, usually 1 - 8 bytes,
> + * *NEVER* to the PIO buffers!!!!!!! use ipath_dwordcpy for longer
> + * copies, or any copy to the PIO buffers. Works for 32 and 64 bit
> + * gcc and pathcc
> + */
> +static __inline__ void ipath_shortcopy(void *dest, void *src, uint32_t cnt)
in kernel land we __inline__ includes always_inline. Also no need for
a separate prototype for a just following inline function.
> +{
> + void *ssv, *dsv;
> + uint32_t csv;
> + __asm__ __volatile__("cld\n\trep\n\tmovsb":"=&c"(csv), "=&D"(dsv),
> + "=&S"(ssv)
> + :"0"(cnt), "1"(dest), "2"(src)
> + :"memory");
> +}
No way we're gonna put assembler code into such a driver.
> +struct ipath_int_vec {
> + int long long addr;
> + uint32_t info;
> +};
please always used fixes-size types for user communication. also please
avoid ioctls like the rest of the IB codebase.
> +/* Similarly, this is the kernel version going back to the user. It's slightly
> + * different, in that we want to tell if the driver was built as part of a
> + * PathScale release, or from the driver from the OpenIB, kernel.org, or a
> + * standard distribution, for support reasons. The high bit is 0 for
> + * non-PathScale, and 1 for PathScale-built/supplied. That bit is defined
> + * in Makefiles, rather than this file.
> + *
> + * It's returned by the driver to the user code during initialization
> + * in the spi_sw_version field of ipath_base_info, so the user code can
> + * in turn check for compatibility with the kernel.
> +*/
> +#define IPATH_KERN_SWVERSION ((IPATH_KERN_TYPE<<31) | IPATH_USER_SWVERSION)
NACK, there's no way we're gonna put in a way to identify an "official"
version. The official version is the last one in mainline always.
> +#ifndef PCI_VENDOR_ID_PATHSCALE /* not in pci.ids yet */
> +#define PCI_VENDOR_ID_PATHSCALE 0x1fc1
> +#define PCI_DEVICE_ID_PATHSCALE_INFINIPATH1 0xa
> +#define PCI_DEVICE_ID_PATHSCALE_INFINIPATH2 0xd
> +#endif
so move it there?
> +typedef struct _ipath_portdata {
please avoid typedefs for struct types.
> +/*
> + * these should be somewhat dynamic someday, although they are fixed
> + * for all users of the device on any given load.
> + *
> + * NOTE: There is a VM bug in the 2.4 Kernels similar to the one Dave
> + * fixed in the 2.6 Kernel. When using large or discontinuous memory,
> + * we get random kernel oops. So, in 2.4, we are just going to stick
> + * with 4k chunks instead of 64k chunks.
> + */
No one cares about 2.4 kernels here.
> + * these function similarly to the mlock/munlock system calls.
> + * ipath_mlock() is used to pin an address range (if not already pinned),
> + * and optionally return the list of physical addresses
> + * ipath_munlock() does the obvious, and ipath_mlock() cleans up all
> + * private memory, used at driver unload.
> + * ipath_mlock_nocopy() is similar to mlock, but only one page, and marks
> + * the vm so the page isn't taken away on a fork.
> + */
> +int ipath_mlock(unsigned long, size_t, struct page **);
> +int ipath_mlock_nocopy(unsigned long, struct page **);
this kind of thing definitly doesn't belong into an LLDD. or maybe
it's just stale prototypes?
> +#ifdef IPATH_COSIM
> +extern __u32 sim_readl(const volatile void __iomem * addr);
> +extern __u64 sim_readq(const volatile void __iomem * addr);
> +extern void sim_writel(__u32 val, volatile void __iomem * addr);
> +extern void sim_writeq(__u64 val, volatile void __iomem * addr);
> +#define ipath_readl(addr) sim_readl(addr)
> +#define ipath_readq(addr) sim_readq(addr)
> +#define ipath_writel(val, addr) sim_writel(val, addr)
> +#define ipath_writeq(val, addr) sim_writeq(val, addr)
> +#else
> +#define ipath_readl(addr) readl(addr)
> +#define ipath_readq(addr) readq(addr)
> +#define ipath_writel(val, addr) writel(val, addr)
> +#define ipath_writeq(val, addr) writeq(val, addr)
> +#endif
Please use the proper functions directly. Your simulator can override
them if nessecary.
> +static __inline__ uint32_t ipath_kget_kreg32(const ipath_type stype,
> + ipath_kreg regno)
> +{
> + volatile uint32_t *kreg32;
> +
> + if (!devdata[stype].ipath_kregbase)
> + return ~0;
> +
> + kreg32 = (volatile uint32_t *)&devdata[stype].ipath_kregbase[regno];
volatile use is probably always wrong. but this whole functions looks like
a very odd wrapper anyway?
next prev parent reply other threads:[~2005-12-17 13:15 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20051031150618.627779f1.akpm@osdl.org>
2005-12-16 23:48 ` [PATCH 00/13] [RFC] IB: PathScale InfiniPath driver Roland Dreier
2005-12-16 23:48 ` [PATCH 01/13] [RFC] ipath basic headers Roland Dreier
2005-12-16 23:48 ` [PATCH 02/13] [RFC] ipath debug header Roland Dreier
2005-12-16 23:48 ` [PATCH 03/13] [RFC] ipath copy routines Roland Dreier
2005-12-16 23:48 ` [PATCH 04/13] [RFC] ipath LLD core, part 1 Roland Dreier
2005-12-16 23:48 ` [PATCH 05/13] [RFC] ipath LLD core, part 2 Roland Dreier
2005-12-16 23:48 ` [PATCH 06/13] [RFC] ipath LLD core, part 3 Roland Dreier
2005-12-16 23:48 ` [PATCH 07/13] [RFC] ipath core misc files Roland Dreier
2005-12-16 23:48 ` [PATCH 08/13] [RFC] ipath core last bit Roland Dreier
2005-12-16 23:48 ` [PATCH 09/13] [RFC] ipath IB driver headers Roland Dreier
2005-12-16 23:48 ` [PATCH 10/13] [RFC] ipath verbs, part 1 Roland Dreier
2005-12-16 23:48 ` [PATCH 11/13] [RFC] ipath verbs, part 2 Roland Dreier
2005-12-16 23:48 ` [PATCH 12/13] [RFC] ipath verbs MAD handling Roland Dreier
2005-12-16 23:48 ` [PATCH 13/13] [RFC] ipath Kconfig and Makefile Roland Dreier
2005-12-17 21:52 ` Adrian Bunk
2005-12-17 22:54 ` [openib-general] " Robert Walsh
2005-12-17 23:55 ` Adrian Bunk
2005-12-18 1:17 ` Robert Walsh
2005-12-18 0:27 ` Alan Cox
2005-12-18 19:23 ` Sam Ravnborg
2005-12-20 0:32 ` [openib-general] " Robert Walsh
2005-12-26 2:49 ` Roland Dreier
2005-12-18 19:59 ` [PATCH 10/13] [RFC] ipath verbs, part 1 Paul E. McKenney
2005-12-18 20:05 ` [openib-general] " Robert Walsh
2005-12-19 20:50 ` Ralph Campbell
2005-12-17 20:38 ` [PATCH 08/13] [RFC] ipath core last bit Andrew Morton
2005-12-21 0:00 ` Robert Walsh
2005-12-17 20:38 ` [PATCH 07/13] [RFC] ipath core misc files Andrew Morton
2005-12-17 21:29 ` Robert Walsh
2005-12-17 21:33 ` Robert Walsh
2005-12-18 3:10 ` Andrew Morton
2005-12-18 3:13 ` Robert Walsh
2005-12-17 20:38 ` [PATCH 04/13] [RFC] ipath LLD core, part 1 Andrew Morton
2005-12-17 21:34 ` Robert Walsh
2005-12-17 12:38 ` [PATCH 03/13] [RFC] ipath copy routines Pekka Enberg
2005-12-17 21:38 ` Robert Walsh
2005-12-17 13:16 ` Christoph Hellwig
2005-12-17 20:38 ` Andrew Morton
2005-12-17 22:40 ` Robert Walsh
2005-12-18 3:19 ` Andrew Morton
2005-12-18 3:35 ` Adrian Bunk
2005-12-18 5:33 ` Robert Walsh
2005-12-18 9:33 ` David S. Miller
2005-12-18 19:52 ` Robert Walsh
2005-12-18 3:27 ` Andi Kleen
2005-12-18 5:36 ` Robert Walsh
2005-12-18 5:41 ` Andi Kleen
2005-12-18 13:25 ` Alan Cox
2005-12-17 12:33 ` [PATCH 01/13] [RFC] ipath basic headers Pekka Enberg
2005-12-17 21:55 ` Robert Walsh
2005-12-17 13:14 ` Christoph Hellwig [this message]
2005-12-17 21:51 ` Eric W. Biederman
2005-12-18 3:25 ` Andi Kleen
2005-12-18 15:02 ` Eric W. Biederman
2005-12-17 22:19 ` Robert Walsh
2005-12-17 22:25 ` Arjan van de Ven
2005-12-17 22:47 ` Robert Walsh
2005-12-17 20:38 ` Andrew Morton
2005-12-17 22:39 ` Robert Walsh
2005-12-18 3:14 ` Andrew Morton
2005-12-20 1:43 ` Robert Walsh
2005-12-17 13:16 ` [PATCH 00/13] [RFC] IB: PathScale InfiniPath driver Christoph Hellwig
2005-12-17 15:51 ` Roland Dreier
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=20051217131456.GA13043@infradead.org \
--to=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openib-general@openib.org \
--cc=rolandd@cisco.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome