Re: [PATCH] ARM: remove ARM710 specific assembler code

[Catalin Marinas]

On Sat, May 17, 2014 at 11:26:38AM +0100, Russell King - ARM Linux wrote:
> On Sat, May 17, 2014 at 10:56:02AM +0100, Catalin Marinas wrote:
> > > The difference between what you're proposing and what happened to ARMv3
> > > is that ARMv3 was broken for quite some time (we read from some of the
> > > CP15 registers which are read-only in ARMv3) and no one ever raised a
> > > problem with that.  So, after a sufficient period of time, it got removed
> > > - and no one batted an eyelid.  That's the correct way to do it - allow
> > > code to age, and if no one notices it's been broken, then it can be
> > > removed.
> > 
> > Iâm more for pro-actively âbreakingâ it with a DEPRECATED
> > dependency. For example, if you suspect that some code like ARM710T is
> > no longer in use, we mark it and see if anyone complains about this over
> > a two years period. If not, it gets removed.
> > 
> > Waiting for code to get broken is another way but itâs less
> > predictable.
> 
> When code being used gets broken, it's nice to think that we'll get
> bug reports which will tell us if it's still being used.

But if you don't get any reports, you can't really whether it's broken
(just because it compiles doesn't mean it still works). So we end up
with keeping code in the kernel for much longer than necessary.

> The problem
> with DEPRECATED is that it will get lost amongst all the thousands
> of other config options and won't be noticed.  Just like EXPERIMENTAL
> or any of the other similar options we've had.

DEPRECATED is meant for documenting the planned removal. If people
complain afterwards, it's their problem for not reporting it earlier.

But we can make it even clearer by adding "depends on n" for DEPRECATED
or just making it not user selectable, so that people would need to
actively change the Kconfig source. They can't complain they haven't
noticed.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/