On 02.05.22 17:10, Jakub Kicinski wrote: > On Mon, 02 May 2022 08:29:03 -0600 Jonathan Corbet wrote: >> Jakub Kicinski 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