Driver graveyard
Subsystems (2)
Hi!
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
I have no idea how to name such a file.
Jonathan Corbet
maintainerQuoted 11 lines · Jakub Kicinski
Hi!
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.
Quoted 4 lines
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.
Thanks,
jon
Quoted 16 lines · On Mon, 02 May 2022 08:29:03 -0600 Jonathan Corbet wrote:
Quoted 9 lines · Jakub Kicinski
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.Quoted 4 lines
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
Quoted 4 lines
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.
Quoted 35 lines · Jakub Kicinski
Quoted 16 lines · On Mon, 02 May 2022 08:29:03 -0600 Jonathan Corbet wrote:
Quoted 9 lines · Jakub Kicinski
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.Quoted 4 lines
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:865e2eb08f51Quoted 4 lines
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
MAINTAINERSentries. 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.
Quoted 4 lines
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
Quoted 18 lines · Jonathan Corbet
Quoted 11 lines · Jakub Kicinski
Hi!
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.Quoted 4 lines
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
Quoted 4 lines
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.
I can imagine it being potentially useful if someone wants to resurect a driver, that file would be easier to search than the git history, but maybe web search engines will keep linking to older kernel sources for long enough.
On a side note, navigating removals is something git doesn't make easy:
git blame will tell when a line has been added (or modified), but figuring out when a line has been removed is more difficult. Or is it one of git's features that I simply don't know about ?
Signature · 3 lines
Regards, Laurent Pinchart
Quoted 5 lines · Laurent Pinchart
On a side note, navigating removals is something git doesn't make easy:
git blame will tell when a line has been added (or modified), but figuring out when a line has been removed is more difficult. Or is it one of git's features that I simply don't know about ?
I find 'git log -p' to almost always be more useful than 'git blame' when trying to
find out what happened to a file.
What I tend to do is to start with 'git grep $KEYWORD v3.0' (or 2.6.12, 4.0, 5.0 etc)
to see what file mentioned something, and then 'git log -p -- $FILENAME' to see the
commits leading up to the removal.
One bit I find missing though is for 'git log --follow' to track renames from $FILENAME
to a new location, rather than following where it came from.
Arnd