> Quoting Roland Dreier <[EMAIL PROTECTED]>: > 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 _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
