On Thu, Oct 04 2007, Arnd Bergmann wrote:
> On Thursday 04 October 2007, you wrote:
> > This looks a lot better! I don't mind seperating the block bits, when we
> > get the whole bunch in there. Just seemed overly silly and complicated
> > to do it for just one ioctl command. When you are happy wit
On Thursday 04 October 2007, you wrote:
> This looks a lot better! I don't mind seperating the block bits, when we
> get the whole bunch in there. Just seemed overly silly and complicated
> to do it for just one ioctl command. When you are happy with this patch,
> I'll add it to the pending block s
On Thu, Oct 04 2007, Arnd Bergmann wrote:
> On Wednesday 03 October 2007, Arnd Bergmann wrote:
> > Jens, I think the best overall solution would be to have a
> > block/compat_ioctl.c file with all the compat handling for block
> > devices moved over from fs/compat_ioctl.c, and done in a nicer way.
On Wednesday 03 October 2007, Arnd Bergmann wrote:
> Jens, I think the best overall solution would be to have a
> block/compat_ioctl.c file with all the compat handling for block
> devices moved over from fs/compat_ioctl.c, and done in a nicer way.
> If you agree, with this approach, I'd volunteer
Here's my counterproposal for the blktrace compat code. It doesn't have
any of the problems I found in your patch obviously, but I haven't tested
it either, so I'm sure you can spot a bug or two in here. Comments?
Jens, I think the best overall solution would be to have a
block/compat_ioctl.c file
On Tuesday 02 October 2007, Jens Axboe wrote:
> Hi Arnd,
>
> Updated patch below. I kept the code in compat_ioctl.c, to me it seems
> like the cleanest approach. I need the BLKTRACESETUP32 define both in
> compat_ioctl.c and blktrace.c if I move it, and I need to hard-core the
> struct size or def
Hi Arnd,
Updated patch below. I kept the code in compat_ioctl.c, to me it seems
like the cleanest approach. I need the BLKTRACESETUP32 define both in
compat_ioctl.c and blktrace.c if I move it, and I need to hard-core the
struct size or define it in both places. And guard the code in
blktrace.c wi
On Tue, Oct 02 2007, Arnd Bergmann wrote:
> On Tuesday 02 October 2007, Jens Axboe wrote:
> >
> > The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
> > padded differently on 32-bit and 64-bit archs. So right now it's not
> > possible to trace 64-bit kernels with a 32-bit app.
On Tuesday 02 October 2007, Jens Axboe wrote:
>
> The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
> padded differently on 32-bit and 64-bit archs. So right now it's not
> possible to trace 64-bit kernels with a 32-bit app. This patch fixes
> that up by adding a compat ioctl
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Tue, 2 Oct 2007 09:39:43 +0200
> Hi,
>
> The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
> padded differently on 32-bit and 64-bit archs. So right now it's not
> possible to trace 64-bit kernels with a 32-bit app. This patch fixes
Hi,
The layout of struct blk_user_trace_setup is a bit unfortunate, it gets
padded differently on 32-bit and 64-bit archs. So right now it's not
possible to trace 64-bit kernels with a 32-bit app. This patch fixes
that up by adding a compat ioctl handler for BLKTRACESETUP.
Signed-off-by: Jens Axb
11 matches
Mail list logo
