Have the drm.git kernel modules been abandoned?

[mdias]

This is exactly why the drivers should be included in the kernel tree and adapt to changes change by change instead of eg every kernel version.

Sorry, you misunderstood my question.
agd5f did get to the point I was after. No offense intended


@lbcoder: you're mostly out of context on your replies. I talked about the BIOS issue as just an example of something that can go wrong for example.

I'm not gonna turn this thread into a fglrx discussion as it's a matter of needs and personal preference.

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.

Why other than that's what windows does?

Ease of installation of just that module. And to give people who don't want to release the code the freedom to do so.

[pvtcupcakes]

Ease of installation of just that module. And to give people who don't want to release the code the freedom to do so.

AFAIK vendors can submit a small part of their driver to the kernel, and then have their binary blob hook into that.
I think VIA (OpenChrome?) tried it recently, but got rejected. Might have just been poor code quality; I don't remember.

[nhaehnle]

AFAIK vendors can submit a small part of their driver to the kernel, and then have their binary blob hook into that.
I think VIA (OpenChrome?) tried it recently, but got rejected. Might have just been poor code quality; I don't remember.

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.

On a sidenote, I occasionally wished that not just kernel drivers, but actually the userspace components of 3D drivers were part of the same repository. After all, 3D driver design is really an exokernel design, and it is kind of annoying to have pretend that the userspace interface is a userspace interface, when in fact it is really just a tightly coupled communication link between kernel module and userspace driver. At least that's my story.

[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.

[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.

[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.

[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.

[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.

[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]

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