linux-kernel - Re: [git pull] drm request 3

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: <20100305154201.4885c9c2@lxorguk.ukuu.org.uk>
Date:	Fri, 5 Mar 2010 15:42:01 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	David Miller <davem@...emloft.net>
Cc:	daniel@...ishbar.org, skeggsb@...il.com, airlied@...ux.ie,
	linux-kernel@...r.kernel.org, jbarnes@...tuousgeek.org,
	dri-devel@...ts.sf.net, mingo@...e.hu,
	torvalds@...ux-foundation.org
Subject: Re: [git pull] drm request 3

> Personally I wouldn't have ever committed to that "user visible APIs
> can break cause it's in -stable."  Because that's complete garbage

Staging has to have the no API rules. Read some of the stuff in there to
understand why or apply about 30 seconds of thought to what it would mean
to you.

There are staging drivers using old wireless layers. If you say that no
API can be broken from staging then you will have to put the old wireless
compatibility into your network code forever. Does that fill you with
joy, light and happiness ?

Whether nouveau should ever have gone into staging is a different
question.

I don't personally think its all as clear cut as it might seem. Quite a
few distributions ship whacky wireless drivers with old API's as the
choice is that or nothing. They manage the user expectation and they deal
with the drivers moving from one wireless stack to the other and
mostly successfully hide it in userspace.

The differences here appear to be
- Having no video is more annoying than having no wireless
- Userspace failed to hide it (so maybe its not a kernel ABI problem but
  a failure to anticipate the need for versioned libdrm and the
  importance in some eyes of supporting the kernel.org kernel - which
  like it or not is a corner case for distro *users*).
- The box it broke happened to belong to Linus

but that doesn't really require tantrums or fingerpointing to fix,
particularly when its only the combination of a set of decisions and
misunderstandings by Linus, Fedora and the Nouveau developers together
that combined to create the mess.

Alan

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