linux-kernel - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140531022151.GA32348@kroah.com>
Date:	Fri, 30 May 2014 19:21:51 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Sune Mølgaard <sune@...gaard.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Summarizing deprecations

On Sat, May 31, 2014 at 04:04:05AM +0200, Sune Mølgaard wrote:
> 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.

Not true at all.

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

It was a success.  Do you know of any hardware that Linux currently does
not support that a vendor wants a Linux driver for it?  I do not.

If you do, send them to me, I'll be glad to work on it, much like all of
the other drivers we have worked on in this program over the years.

Of course, if the vendor doesn't want a Linux driver for their hardware,
well, there's nothing anyone of us can do about that.

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

Have you looked at the kernel backport group and scripts?  They do much
of this already, automatically, backporting newer drivers to older
kernel versions for people stuck at those releases.  I think what you
want is already completed...

thanks,

greg k-h
--
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/