> > +#ifdef IPATH_COSIM
> > +extern __u32 sim_readl(const volatile void __iomem * addr);
> > +extern __u64 sim_readq(const volatile void __iomem * addr);
>
> The driver has a strange mixture of int32_t, s32 and __s32. s32 is
> preferred.
The cosim stuff has been nuked, as it was old code anyway.
Andi Kleen <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Eric W. Biederman) writes:
>
>> Christoph Hellwig <[EMAIL PROTECTED]> writes:
>>
>> > please always used fixes-size types for user communication. also please
>> > avoid ioctls like the rest of the IB codebase.
>>
>> Could someone pleas
[EMAIL PROTECTED] (Eric W. Biederman) writes:
> Christoph Hellwig <[EMAIL PROTECTED]> writes:
>
> > please always used fixes-size types for user communication. also please
> > avoid ioctls like the rest of the IB codebase.
>
> Could someone please explain to me how the uverbs abuse of write
> i
Robert Walsh <[EMAIL PROTECTED]> wrote:
>
> > I'd be inclined to stick BITS_PER_BYTE into include/linux/types.h.
>
> Really? I was just going to suggest removing it, but if sticking it in
> types.h works for you, then fine.
>
I think it's a readbility thing.
x += 8; /*
> and opterons can already run 2 architectures. And the HT bus is a
> generic bus.. with public specs. Others than just AMD use it as well.
>
> also.. what is wrong with memcpy and co ?
Our chips can only handle double-word writes. memcpy isn't guaranteed
to do this.
> then you need to use read
> > +#define yield() sched_yield()
>
> Some might get upset about what I assume is userspace test harness code or
> what _is_ this doing?) in a driver. But if the maintainers find it useful
> we can live with it,
That is cosimulator code. It's easy enough to remove. I'll look into
it.
> > +#i
On Sat, 2005-12-17 at 14:19 -0800, Robert Walsh wrote:
> > > +{
> > > + 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)
> > > +
> > + * $Id: ipath_common.h 4491 2005-12-15 22:20:31Z rjwalsh $
>
> please remove RCSIDs everywhere.
These are everywhere in the OpenIB code. I was actually asked by one of
the OpenIB developers to include them. I'm happy to remove them again,
but what do the OpenIB folks think?
> > +#define y
> Do we really need this ugly userspace emulation code in the kernel?
Probably not. I'll look into removing it.
> What is this used for? Why can't yo use memcpy?
Our chip can only handle double-word copies.
> > +#define round_up(v,sz) (((v) + (sz)-1) & ~((sz)-1))
>
> Please use ALIGN().
Fair
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> please always used fixes-size types for user communication. also please
> avoid ioctls like the rest of the IB codebase.
Could someone please explain to me how the uverbs abuse of write
is better that ioctl?
Every single command seems to have a
Roland Dreier <[EMAIL PROTECTED]> wrote:
>
> ...
>
> +#ifdef __KERNEL__
> +#include
> +#include
> +#include
> +#else/* !__KERNEL__; user mode */
> +#include
> +#include
> +#include
> +#include
> +
> +/* these aren't implemented for user mode, which is OK until
> + * $Id: ipath_common.h 4491 2005-12-15 22:20:31Z rjwalsh $
please remove RCSIDs everywhere.
> +#ifdef __KERNEL__
> +#include
> +#include
> +#include
> +#else/* !__KERNEL__; user mode */
> +#include
> +#include
> +#include
> +#include
> +
> +/* these aren'
Hi Roland,
On 12/17/05, Roland Dreier <[EMAIL PROTECTED]> wrote:
> +/*
> + * This file contains defines, structures, etc. that are used
> + * to communicate between kernel and user code.
> + */
> +
> +#ifdef __KERNEL__
> +#include
> +#include
> +#include
> +#else /* !__
13 matches
Mail list logo
