On Sat, Jan 13, 2001 at 05:06:16PM +0100, Christoph Hellwig wrote:
> On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> > Anton, you write:
> > > Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
> >
> > Yuk.
> >
> > > Would it be possible to clean up the ioctl interface so we
On Sat, Jan 13, 2001 at 05:06:16PM +0100, Christoph Hellwig wrote:
On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
Anton, you write:
Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
Yuk.
Would it be possible to clean up the ioctl interface so we dont need
such
> The longs are the biggest problem AFAICS.
> long is 64bit on sparc64 and 32bit on sparc32...
Embedding pointers in ioctls is much worse. When this happens we basically
end up duplicating the ioctl parsing code (this code courtesy of jakub's
sharp mind, but it would be nice not to require
On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
> Anton, you write:
> > Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
>
> Yuk.
>
> > Would it be possible to clean up the ioctl interface so we dont need
> > such large hacks for LVM support? I can do the work but I want to be
On Fri, Jan 12, 2001 at 06:43:23PM -0700, Andreas Dilger wrote:
Anton, you write:
Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
Yuk.
Would it be possible to clean up the ioctl interface so we dont need
such large hacks for LVM support? I can do the work but I want to be
sure you
The longs are the biggest problem AFAICS.
long is 64bit on sparc64 and 32bit on sparc32...
Embedding pointers in ioctls is much worse. When this happens we basically
end up duplicating the ioctl parsing code (this code courtesy of jakub's
sharp mind, but it would be nice not to require this
6 matches
Mail list logo
