Driver graveyard

Driver graveyard

[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.


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.

Re: Driver graveyard

[Jonathan Corbet]

Jakub Kicinski <kuba@kernel.org> writes:

> 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

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

Re: Driver graveyard

[Jakub Kicinski]

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.

Re: Driver graveyard

[Juergen Gross]

[-- 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 --]

Re: Driver graveyard

[Laurent Pinchart]

On Mon, May 02, 2022 at 08:29:03AM -0600, Jonathan Corbet wrote:
> Jakub Kicinski <kuba@kernel.org> writes:
> 
> > 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
> 
> 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 ?

-- 
Regards,

Laurent Pinchart

Re: Driver graveyard

[Arnd Bergmann]

On Mon, May 2, 2022 at 5:18 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> 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