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: <21d7e9971003041125x1aee3b3ew1e407ca6695e10fc@mail.gmail.com>
Date:	Fri, 5 Mar 2010 05:25:34 +1000
From:	Dave Airlie <airlied@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Dave Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
	dri-devel@...ts.sf.net
Subject: Re: [git pull] drm request 3

>>
>> If marking the driver as staging doesn't allow them to break ABI when
>> they need to, then it seems like they'll have no choice but to either
>> remove the driver from upstream and only submit it when the ABI is
>> stable, or fork the driver and submit a new one only when the ABI is
>> stable.  Neither seem particularly attractive.
>
> The thing is, they clearly didn't even _try_ to make anything compatible.
> See how all the ioctl numbers were moved around.
>
> And if you can't make if backwards compatible, at least you should make it
> forwards-compatible. Is it even that? I don't know. I'm kind of afraid it
> isn't. The new libdrm required for it certainly hasn't been pushed to
> Fedora-12. Will it ever be? And if it is, can you still run an old kernel
> on it?
>
> All of these are always possible to do. We've been _very_ good at doing
> them in general. I'm complaining, because let's face it, what else can I
> do?
>
> And btw, I'd complain about breaking backwards compatibility even if it
> wasn't just my own machine. I can pretty much guarantee that I'm not going
> to be the only one hitting this issue.
>
> So practically speaking: what _do_ you suggest we do about all the
> regressions this will cause?

At the moment in Fedora we deal with this for our users, we have dependencies
between userspace and kernel space and we upgrade the bits when they upgrade
the kernels, its a pain in the ass, but its what we accepted we needed
to do to get
nouveau in front of people. We are currently maintain 3 nouveau APIs
across F11, F12
and F13.

The main reason the API was gutted was because it supported lots of
things that weren't
supportable going forward. User modesetting support was completely
removed and this
meant lots of the API was pointless.

Now I can ask Ben if he'd like to try and supply a libdrm that could
in  theory deal
with both as a favour, but I'm not expecting the nouveau project guys
to care, we pretty
much got ourselves into this corner, and we'll pretty much have to get
ourselves out.

The other option I can ask him to look at is a CONFIG_NOUVEAU_015 interface
which justs ifdefs around this for now, and in another release or two
we rip all that out.

Of course I can't ask him either of these until normal people who live
in Australia wake
up in 2-3 hrs, as opposed to me who is sitting in the dark trying not
to wake the baby.

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