On Thu, Oct 31, 2002 at 02:00:31PM +1100, Rusty Russell wrote:
> > > EVMS
> >
> > Not for the feature freeze, there are some noises that imply that SuSE may
> > push it in their kernels.
>
> They have, IIRC. Interestingly, it was less invasive (existing source
> touched) than the LVM2/DM patch you merged.
FUD. I added to three areas of existing code:
i) Every man and his dog uses mempools in conjuction with slabs, so
rather than having everyone redefining their own alloc/free
functions I added the following huge functions to mempool.c. In no
way were they mandatory.
/*
* A commonly used alloc and free fn.
*/
void *mempool_alloc_slab(int gfp_mask, void *pool_data)
{
kmem_cache_t *mem = (kmem_cache_t *) pool_data;
return kmem_cache_alloc(mem, gfp_mask);
}
void mempool_free_slab(void *element, void *pool_data)
{
kmem_cache_t *mem = (kmem_cache_t *) pool_data;
kmem_cache_free(mem, element);
}
ii) vcalloc, this *didn't* get merged, and will probably end up getting
moved into dm.h.
iii) ioctl32 support: people have argued against an ioctl interface,
and I'm inclined to agree with them, which is why I'm going to
publish an fs interface shortly. However, given that we are
currently using an ioctl interface how do we avoid adding support for
32bit userland/64 kernel space ? If EVMS isn't touching these
files does that mean they're not supporting these architectures ?
arch/mips64/kernel/ioctl32.c
arch/ppc64/kernel/ioctl32.c
arch/s390x/kernel/ioctl32.c
arch/sparc64/kernel/ioctl32.c
So given that (ii) didn't get merged, which of (i) and (iii) were you
objecting to ?
- Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:53 EST