Have the drm.git kernel modules been abandoned?

[nhaehnle]

You are correct. But the problem is that apparently no one will accept a nice interface to be included in the kernel for the sole purpose of supporting binary blobs, just because it's binary, no matter who developed it.

Have there even been serious attempts at such in-kernel interfaces? Somehow, I doubt it - because all the people who scream for binary interfaces are usually just screamers, and not doers.

On the other hand, FUSE and now CUSE are perfectly fine binary driver interfaces that have been accepted into the kernel without too much fuss. I think it's a very good solution to the problem: If you insist on writing binary blob drivers, you can go to userspace and play microkernel.

[mdias]

Is somebody preventing this?

I don't think so. It's unfair to expect kernel hackers to spend extra time making sure third-party binary drivers are working. It's the job of the writers of the said drivers.

They are free to support them, nobody is taking this away.

You are correct. But the problem is that apparently no one will accept a nice interface to be included in the kernel for the sole purpose of supporting binary blobs, just because it's binary, no matter who developed it.

[pingufunkybeat]

Freedom as in being able to support binary drivers in a stable and legal way.

Is somebody preventing this?

I don't think so. It's unfair to expect kernel hackers to spend extra time making sure third-party binary drivers are working. It's the job of the writers of the said drivers.

They are free to support them, nobody is taking this away.

[mdias]

Freedom of kernel hackers to develop the kernel the way they think is best?

Or which freedom?

Freedom as in being able to support binary drivers in a stable and legal way.
Meaning that open source devs as well as closed source devs should be able to do it without major problems.


[edit] uhh, what a coincidence.
I'm aware that having those binary interfaces would add up to the problem, but it seems that embedding drivers on the kernel is also starting to be a problem...

[pingufunkybeat]

If that's the case then so much for freedom I guess...

Freedom of kernel hackers to develop the kernel the way they think is best?

Or which freedom?

[mdias]

No, I'm afraid not.
Your problem is your lack of understanding and/or your clarity of statement.

If my responses appear to be out of context, then that is due to your statements being worded differently than your intended meaning.

Well, I'm sorry english is not my native language. Others appeared to understand my point as I meant it to be understood.

Fact is this;
Linux is NOT INTENDED to allow you to make closed source drivers. It is in fact quite the reverse -- it is intended to FORCE you to make OPEN SOURCE drivers for many reasons, some of which I have outlined. That isn't going to change. If you don't like that, then this isn't the appropriate platform for you and you should therefore concentrate on something else. This platform is there for those who agree with or NEED this policy...

If that's the case then so much for freedom I guess...
I don't see linux to be what you say it is, and not liking one feature of an OS can be not enough to make me change my opinion about it, specially since I'm an application developer and not a kernel driver dev.

The same statements I have made are applicable regardless of what particular issue you invent to be representative of worst-case-scenario.

You missed my point again. AMD must not damage my hardware, be it wiping the BIOS or whatever. The open source driver devs do not have to guarantee you anything.

Bad spelling aside, at what point in the process do you observe anonymous contributions being blindly accepted into mainline? All of the major components have some responsible overseer and testing process to verify quality of code.

Again, english isn't my native language, but I'm sure I can communicate in an understandable manner. I can't see how that kind of observation helps this discussion.

I never mentioned the code being blindly accepted. The fact is that bugs can slip through everyone's eyes.

[lbcoder]

@lbcoder: you're mostly out of context on your replies.

No, I'm afraid not.
Your problem is your lack of understanding and/or your clarity of statement.

If my responses appear to be out of context, then that is due to your statements being worded differently than your intended meaning.

Fact is this;
Linux is NOT INTENDED to allow you to make closed source drivers. It is in fact quite the reverse -- it is intended to FORCE you to make OPEN SOURCE drivers for many reasons, some of which I have outlined. That isn't going to change. If you don't like that, then this isn't the appropriate platform for you and you should therefore concentrate on something else. This platform is there for those who agree with or NEED this policy...

I talked about the BIOS issue as just an example of something that can go wrong for example.

The same statements I have made are applicable regardless of what particular issue you invent to be representative of worst-case-scenario.

I AM going to say that OSS devs DON'T have to support me though. I could anonimously contribute with code and I'd have nothing to lose from ignoring users' questions.

Bad spelling aside, at what point in the process do you observe anonymous contributions being blindly accepted into mainline? All of the major components have some responsible overseer and testing process to verify quality of code.

[krazy]

VMWare's "VMI" interface anyone? It got welcomed with open arms...

No it didn't. It got rejected, and made to "plug-in" to paravirt_ops, precisely because kernel hackers didn't want to be responsible for a stable ABI. paravirt_ops is also used by Xen and Lguest.

[amphigory]

I love such lively debate regarding imponderable conundrums. ;-) Next thing you know the microkernel / monolithic argument will raise its ugly head again.

Myself... I'm just enjoying the beauty of a stable unified video driver and don't worry too much about design philosophy. Oh yes... and wondering what to do with the NVIDIA card I replaced with AMD.

[RealNC]

No, they can't.

The kernel has a rather strict policy about keeping the userspace interfaces stable. If the only client of a userspace interface is a binary blob, then you have an extremely weak case for inclusion into the kernel.

VMWare's "VMI" interface anyone? It got welcomed with open arms...

Oh, and two days ago, they announced that their VMWare products will stop using VMI anyway and announced that they will remove VMI from the kernel because of that.

It seems some "binary blobs" get preferential treatment.