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: <ff13bc9a1003051239w6816e789m70bea7e34820d858@mail.gmail.com>
Date:	Fri, 5 Mar 2010 21:39:01 +0100
From:	Luca Barbieri <luca.barbieri@...il.com>
To:	Eric Anholt <eric@...olt.net>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Jeff Garzik <jeff@...zik.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

> So overall, I'd say that we spent about a month of developer time
> at least between jbarnes, ickle, and myself, on extending the execbuf
> interface to add a flag saying "dear kernel, please don't do this bit of
> work on this buffer, because I don't need it and it makes things slow."

Perhaps then, we should break ABI compatibility _more_ often to speed
up development, but also have awesome mechanisms to make it painless
for the user.

Such as:
1. Automatic side by side userspace installation, as Linus proposed
2. Kernel "make install" refusing to proceed if it finds that
userspace is not updated, and giving instructions on how to update
userspace
3. Distributions packaging the new ABI X/Mesa drivers and libdrm even
for stable distributions
4. Kernel "make install" offering to automatically install said
distribution packages if it detects a supported distribution
5. Ability to drop new versions of drivers/gpu/drm in an older kernel
tree and have it compile (within reasonable limits)

In particular, for people with (slightly) old kernels, it should be
much easier to make updated DRM trees still work with older kernels,
than attempting to make updated userspace work with older kernel
modules.
This also actually gives them the benefits of the new code.

And for people with really old kernels, it's not different from any
other hardware device, which requires a kernel upgrade to have better
support.

Then, for instance, Linus would just have seen the following upon
running make install:
This kernel requires the Nouveau userspace version 0.0.16, which you
don't have installed.
Fedora 12 has been detected.
Invoke yum to install the <rpmnames> RPMs required for it? [y/n]
_or_
Ubuntu 9.10 has been detected
Invoke apt-get to install the <debnames> packages required for it? [y/n]

If the user says no, or the distribution is unknown, instructions on
how to download and compile the source would be presented.

Once you setup this system, you can freely break the ABI with no
significant user discomfort by just raising the version number.
This also potentially applies to stuff other than DRM (e.g. perf, kvm,
iptables, udev, filesystem-specific tools/APIs, various device
configuration systems, and so on).

The really stable APIs/ABIs should not be the (undocumented) kernel
ones, but Xlib and OpenGL, which actually have formal specifications.
Perhaps eventually Gallium could join them as a stable API closer to
the hardware, but that's a long way off.
--
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/