X.Org Server Development Process Is Questioned

[uid313]

revoke() is available in BSD.
http://man.cx/revoke%282%29

[leif81]

How about using Gerrit. Require every patch get a couple +1's before it gets (auto?) merged to master.

[daniels]

Why does not Linux have a revoke() after all these years?
There already been patches committed to add this, why have it not been merged?

They don't cover all the corner cases, some of which are viciously hard to deal with. To be honest, I think the best course of action would be an input-specific revoke(), but last time that got proposed, it got shot down in LKML internal bitchfights.

[uid313]

They don't cover all the corner cases, some of which are viciously hard to deal with. To be honest, I think the best course of action would be an input-specific revoke(), but last time that got proposed, it got shot down in LKML internal bitchfights.

I see.

Maybe they should just merge something, and accept a less-than-perfect solution, so have something that kinda does what its supposed to do even if it doesn't cover all the corner cases.
Then later it can be improved in time to mature and further stabilize.

[curaga]

Then they'd be stuck with the inferior solution in kernel forever.

[Ericg]

Then they'd be stuck with the inferior solution in kernel forever.

Yuuuuuuuuuup. Remember, kernel policy is anything that ever hits mainline that userspace can use can never break. Ever. If someone wants to run a motif app from 1995 that was designed around kernel 2.4.12 (im picking a random release number there lol), that app has to work as far as the kernel is concerned. It can break because of userspace changes, thats fine, but if it can't run then it can't be because of kernel changes. If it is because of kernel changes then its considered a bug to be fixed.

Whatever implementation of revoke() goes into the kernel has to be perfect on the first run or extensible enough to not matter.

[uid313]

Hmm, maybe if there were a revoke() implementation as a loadable kernel module?

[Ericg]

Hmm, maybe if there were a revoke() implementation as a loadable kernel module?

That creates a problem of availability. It couldn't be used because it couldn't be guaranteed to be available. And Wayland would probably need it to be available on all systems.

[squirrl]

Something new comes along and they delete the old.

GEM vs EXA vs XXA

Then there was DRI vs DRI2.

Modesetting.

The list grows but I still blame distributions for screaming "Upstream" more than senators scream "Bipartisanship".

It's getting old.

You just can't keep up. I commend Nvidia for keeping up with the Jones'.

[Ericg]

Something new comes along and they delete the old.

GEM vs EXA vs XXA

Then there was DRI vs DRI2.

Modesetting.

The list grows but I still blame distributions for screaming "Upstream" more than senators scream "Bipartisanship".

It's getting old.

You just can't keep up. I commend Nvidia for keeping up with the Jones'.

GEM has nothing to do with EXA and XXA, GEM is still still being used in kernel (Wayland is pretty much dependent on it cuz everything is a GEM object or is a GEM handle)

DRI was supplanted by DRI2...which was in the X server, not the kernel. The x server drops stuff.

Modesetting moved from the X server (userspace) to the kernel (KMS)

Nvidia keeps up because...they replace most of the stack with their own pieces because of cross-platform support


Wanna try again squirrl?