[ofa-general] Re: [PATCH] for-2.6.23 ib/umad: add partition support

[Michael S. Tsirkin]

> Quoting Roland Dreier <rdreier at cisco.com>:
> Subject: Re: [ofa-general] Re: [PATCH] for-2.6.23 ib/umad: add partition support
> 
>  > Ugh. OFED 1.2 (with the old ABI) just went out.
>  > I wonder - is it time to start making the kernel backwards-compatible?
>  > It would be trivial to have userspace supply its own ABI
>  > version and have kernel support both new and old ABI if we want to.
>  > What do you think?
> 
> There's always a balance between keeping cruft in the kernel for
> compatibility and not breaking userspace.  I'm beginning to think the
> right plan in this case might be to rename struct ib_user_mad_hdr to
> struct ib_user_mad_hdr_old, make a new struct ib_user_mad with the
> pkey_index member and add a new ioctl IB_USER_MAD_ENABLE_PKEY_INDEX.
> 
> The ABI version would stay the same, and if someone just opened the
> device and didn't do the IB_USER_MAD_ENABLE_PKEY_INDEX they would get
> the old ABI.  If they do the ioctl then they get the new header.  Also
> we could define that ABI version 6 just has the new struct
> ib_user_mad_hdr and no ioctl.
> 
> Then we could say we were going to switch to the new ABI in a year or
> two.  And print a warning in the kernel log for every application that
> doesn't use the ioctl.

Makes sense. If you like, an ioctl can be replaced with a write:
all 4-byte writes currently return -EINVAL.

This has a small advantage that write gets passed the buffer length
parameter, so it's easier to debug (e.g. strace outputs write buffers).

> I'll try to cook up a kernel patch next week.

To make the interface more future-proof, we can 
ask all new-ABI users to use pwrite with offset 0,
and validate the offset in kernel.
Is this a good idea?

-- 
MST