Re: Driver graveyard

[Juergen Gross <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2119 bytes --]

On 02.05.22 17:10, Jakub Kicinski wrote:
> On Mon, 02 May 2022 08:29:03 -0600 Jonathan Corbet wrote:
>> Jakub Kicinski <kuba@kernel.org> writes:
>>
>>> Thomas suggested that it may be nice to create some form of a record
>>> for drivers which were retired from the tree. I think a code-centric
>>> equivalent of CREDITS could be a good idea.
>>>
>>> Does such a record already exist somewhere? If not any thoughts on
>>> creating a file storing (Kconfig, short description, commit which
>>> removed the driver)? E.g.
>>>
>>>
>>> K: DMASCC
>>> D: Hamradio high-speed (DMA) SCC driver for AX.25. Driver supported
>>> D: Ottawa PI/PI2, Paccomm/Gracilis D: PackeTwin, and S5SCC/DMA boards.
>>> C: 865e2eb08f51
>>
>> So what is the purpose for this file?  And more to the point, I guess:
>> is there a need for it to be strictly machine-readable?  If the
>> objective is to remember our history to minimize our chances of
>> repeating it, something more prose-oriented might work better.
> 
> To be honest I found the existence of the CREDITS file useful when
> removing stale MAINTAINERS entries. A move seems less hostile than
> a erasure (using a very broad definition of "move" in case of drivers).
> Anything that makes people feel more at ease when I remove their driver
> would be helpful.
> 
> The only practical (i.e. not armchair-psychology-based) use I can think
> of is if someone is about to sit down and write a new driver they may
> grep the tree for the name of the HW, and they may find the graveyard
> entry. So I think listing the exact HW supported is useful. That said
> as I'm writing this I'm reminded how old the hypothetical HW in the
> previous sentence likely is.
> 
> I used the machine-readable format following CREDITS. I figured CREDITS
> serves no practical purpose either today, in hindsight that's a bit
> ahistoric.
> 

In case something like this is wanted, maybe it should not be limited to
drivers? I think listing desupport of features (driver, arch, syscall,
fs, whatever) with kernel version and maybe commit would be better.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]