Re: [PATCH 01/15] xfs: update mount options documentation

Dave Chinner
2013-06-28T02:32:15Z

On Fri, Jun 28, 2013 at 12:09:12PM +1000, Dave Chinner wrote:
> On Thu, Jun 27, 2013 at 02:08:31PM -0500, Ben Myers wrote:
> > Hey Dave,
> >
> > On Thu, Jun 27, 2013 at 09:48:14AM -0500, Ben Myers wrote:
> > > On Thu, Jun 27, 2013 at 04:04:45PM +1000, Dave Chinner wrote:
> > > > From: Dave Chinner <dchinner@redhat.com>
> > > >
> > > > Because it's horribly out of date.
> > > >
> > > > And mark various deprecated options as deprecated and give them a
> > > > removal date.
> > > >
> > > > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > > > Reviewed-by: Mark Tinguely <tinguely@sgi.com>
> > >
> > > Regarding removal of these mount options and sysctls: initially these all look
> > > pretty reasonable but we need to be very careful here. I've read some
> > > discussions on lkml that seem to suggest that such interfaces which have been
> > > exported to userspace shouldn't be removed at all. Not that I want to keep
> > > around a bunch of worn out interfaces...
> > >
> > > Applied.
> >
> > On second thought... Not pushed.
> >
> > I'm going to hold off on pushing this one to oss for now because I'm just not
> > comfortable with it yet. I can pull this in sans the removal notices if you
> > want. Lets discuss whether the removal of deprecated mount options and sysctls
> > is acceptable before announcing an intention to remove them. I'm trending no,
> > but I can be flexible if this really is ok.
>
> Mount options are perfectly fine to be removed - they've been given
> deprecated warnings for quite some time now (the most recent is the
> delaylog which has been doing that since 3.1 IIRC). So they are all
> fine to actually remove - 12 months warning is usually considered
> sufficient.
>
> As to the sysctls - they haven't had any effect since 3.5 when the
> xfsbufd was removed, so it's time to mark them deprecated so we can
> remove them in a year's time. That gives anyone using them
> (including distros) plenty of time to fix whatever is using them
> before they get removed.
>
> > I'm thinking of the 3.3 glusterfs and 3.8 pulseaudio reakeage. And I would
> > really like to have a nice holiday weekend. ;)
>
> I think you're being overly paranoid here - I'm simply following the
> normal deprecation protocol here....

Documenation/ABI/README:

We have four different levels of ABI stability, as shown by the four
different subdirectories in this location. Interfaces may chang levels
of stability according to the rules described below.
....
obsolete/
This directory documents interfaces that are still remaining in
the kernel, but are marked to be removed at some later point in
time. The description of the interface will document the reason
why it is obsolete and when it can be expected to be removed.

I think you'll find that what I done follows this policy. If you
really want, I'll move them to Documenation/ABI/obsolete. And, of
course, if removing them proves to be a problem, as Eric said we can
always reinstate them or remove the deprecation notices.

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com