Hi Sakari, On Tue, Oct 04, 2022 at 09:36:56PM +0300, Sakari Ailus wrote: > On Tue, Oct 04, 2022 at 05:29:46PM +0300, Laurent Pinchart wrote: > > > If we ever intend to drop this support, we should warn we're going to do > > > so. Otherwise there's little point in recommending against using it. > > > > I agree. Just saying it's not recommended is pointless. Either we want > > to deprecate this behaviour, which means that it may get removed in the > > future (one option could be to WARN_ONCE() for a few years, although > > even that may not be enough), or we conclude that removing it will never > > be possible, in which case I'd drop the message. > > I think displaying a warning for a few seconds would do it. ;-) ;-) > > > > The > > > spec should document it as deprecated and to be removed in the future as > > > well. (Or alternatively, the warning should be removed altogether.) > > > > I wouldn't document it at all, if it's deprecated it doesn't deserve a > > mention in the spec. It's hard enough for people to understand how to do > > the right thing when reading documentation without being told about the > > things that work but shouldn't be done :-) > > I would document it as deprecated so that application developers reading it > could get the hint. Otherwise they won't (unless they look at the kernel > logs of course). Up to you, I don't have a strong opinion on this. Why do you think that would be better than documenting the non-deprecated behaviour only ? I doubt anyone would read the documentation, realize that the feature is deprecated, and then go fix an application. I may be wrong though, is that why you would like to see a mention of the deprecated feature in the documentation ? -- Regards, Laurent Pinchart
