linux-kernel - [RFC] Summarizing deprecations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <53893895.3040202@molgaard.org>
Date:	Sat, 31 May 2014 04:04:05 +0200
From:	Sune Mølgaard <sune@...gaard.org>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	gregkh@...uxfoundation.org
Subject: [RFC] Summarizing deprecations

Dear list,

In order to keep this non-code RFC brief, allow me to list a few
observations and then a proposal, that I shall be happy to engage in,
but for which I'd like a bit of guidance:

1) System calls get superseded and deprecated on a regular basis
2) Keeping track of deprecations can be difficult
3) HW vendors with out-of-tree drivers allocate too few resources to
handle 1) and 2)
4) Out-of-tree drivers usually fail to take deprecations into
consideration, and then breaking when deprecation leads to removal

A knee-jerk reaction to 3) might be that they all need to shape up, but
experience seems to relegate that reaction to the pile of wishful
thoughts that lead nowhere.

IIRC, Greg K-H once tried to extend an offer to HW vendors to the effect
of helping with opening their code base, with the reward of helping
write drivers. I don't know what came of it, but I imagine that I would
have heard, if it was a roaring success.

As a user first, and only secondly a developer, I'd like my HW to work,
and finding fully supported gear can still be hard if not impossible,
but I imagine that if we had a central place to list deprecations (and,
possibly, "victims" of them), a lot of grief could be avoided by simply
pointing vendors to that central resource and saying "here is what you
need to know for your driver to keep working - now get to it".

As said, I'm more of a user, so I may be unaware of practices already in
place to mark commits as causing deprecation, but if such practices
exist, I should be able to whip up some sort of script that periodically
does a "git log" and collates deprecations into some format that could
then be parsed by a bash script grepping various out-of-tree code bases
and notifies the relevant parties.

I'd be willing to have a go at such functionality as well as hosting the
info (at least until some vendor realizes the value and donates to it),
but I'd hate to go off into too many wrong directions, if those can be
avoided by feedback here.

Best regards,

Sune Mølgaard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/