>ii) vcalloc, this *didn't* get merged, and will probably end up getting
>    moved into dm.h.
>
Yeah, historically we have avoided things like this.
kcalloc gets proposed every year or so too.
>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
>  
>
Well, I'll note that ALSA compartmentalizes their ioctl32 handling 
within their own subsystem, which seems like a decent solution.
That said, [maybe I'm biased <g>], using an fs interface allows one to 
completely eliminate an ioctl32 interface.  That would be the direction 
I would greatly prefer by the time 2.5.x hits the code freeze.
Best regards, and congrats for getting it merged,
    Jeff
-
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/