[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20081203.221254.112572542.davem@davemloft.net>
Date: Wed, 03 Dec 2008 22:12:54 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: dwmw2@...radead.org
Cc: linux-atm-general@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: Re: [PATCH] ATM 32-bit ioctl compatibility
From: David Woodhouse <dwmw2@...radead.org>
Date: Wed, 03 Dec 2008 16:00:31 +0000
> We lack compat ioctl support through most of the ATM code. This patch
> deals with most of it, and I can now at least use BR2684 and PPPoATM
> with 32-bit userspace.
>
> I haven't added a .compat_ioctl method to struct atm_ioctl, because
> AFAICT none of the current users need any conversion -- so we can just
> call the ->ioctl() method in every case. I looked at br2684, clip, lec,
> mpc, pppoatm and atmtcp.
>
> In svc_compat_ioctl() the only mangling which is needed is to change
> COMPAT_ATM_ADDPARTY to ATM_ADDPARTY. Although it's defined as
> _IOW('a', ATMIOC_SPECIAL+4,struct atm_iobuf)
> it doesn't actually _take_ a struct atm_iobuf as an argument -- it takes
> a struct sockaddr_atmsvc, which _is_ the same between 32-bit and 64-bit
> code, so doesn't need conversion.
>
> Almost all of vcc_ioctl() would have been identical, so I converted that
> into a core do_vcc_ioctl() function with an 'int compat' argument.
>
> I've done the same with atm_dev_ioctl(), where there _are_ a few
> differences, but still it's relatively contained and there would
> otherwise have been a lot of duplication.
>
> I haven't done any of the actual device-specific ioctls, although I've
> added a compat_ioctl method to struct atmdev_ops.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@...el.com>
Looks good David, applied to net-next-2.6, thanks!
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists