lkml.org 
[lkml]   [2002]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What's left over.
Joe Thornber wrote:

>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/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.235 / U:2.296 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site