Bringing Up Hardware First In Linux, Then Windows

[dfx.]

not that starting to be pathetic: one guy here talking that good design and planing is nothing compared to bruteforcing random code for all the corner cases, the other says that "stable API" somehow by itself is sign of quality.
no, not the carefully designed code rapidly changing to fit present situation and having with some fallbacks but frozen API for unmaintained one-time-written third-party code to function. riiiight....

here's my example of the work of 'that' stable-API/ABI code you so adore for you:
here i have GA-MA78G-DS3H, Athlon 6000+X2, 2Gb DDR2, Radeon X4730 computer with 3 multimedia devices:
1) bt8xx-based PCI analog receiver
2) b2c2 "skystar2" DVB-S receiver
3) AVermedia AverTV USB2 analog receiver
it having Windows(tv)7(r) 64 bit and Gentoo with 2.6.36 kernel and r600g&xf86-video-ati installed.

Gentoo working flawlessly with #1 and #2. but #3 unfortunately was not reverse-engineered and there is zero feedback from manufacturer so it just dead weight.
But Windows(tm) is so cool that is has no drivers for #1 and #3 whatsoever: official support for #1 is long dropped and unofficial only consists of Vista 32 bit-capable 2005 year or something hacky thingy, #3 is not even mentioned on official website (not A8xx device) anymore. but all that is not interesting part.
the interesting part that is this Windows(tm) is unable do shutdown, reboot or otherwise properly end its existence in the system's memory. it just sitting there for 15-30 minutes and then gruesomely dies. googling revealed that this is very widespread issue and cause is some driver inconsistencies (one guy analyzed coredump from other guy's machine). in my case - b2c2 device drivers (from official page and with official support) trying do some shit with device and bus power states and repeating until OS just shoots itself (only removing them from "device list" _and_ manually removing its files from "Windows" directory helps).
potential problem is not limited to dvb or any device in particular and may happen with anyone with anything.

good fucking code practises here. i say, you love stable API/ABI ways so much - go and "marry" them, just code for OS with those and keep this shit far away from Linux.

And for a start they could make an API promise for X kernel versions and see how that turns out.

and the next time some developer will write: "hey, guys, i think <this> can be better, just change it like this and like that. here, i got a patch for you!".
they should answer with: "are you nuts ? you can't do that, we are keeping API fidelity for dudes on the Internets! they say that is only good way for kernel development and this is only way we can find enough vendor support to run it on those pesky x86 machines we have almost 0 drivers. and we also think we should remake kernel to be micro - that will show them that we mean business"

humor us, just write your API/ABI proposal on LKML and not forget to add that entire kernel API should be like this, because it shows quality and stuff. i would really like to read some replies.

PS: and don't start that "officially supported", "discontinued", "this is third-party fault" on me or whatnot. you talking about different models, that are performance results of those models in action.
but they, probably, _just didn't tested my case_, riiight ? ;)

[mat69]

[...]
and the next time some developer will write: "hey, guys, i think <this> can be better, just change it like this and like that. here, i got a patch for you!".
they should answer with: "are you nuts ? you can't do that, we are keeping API fidelity for dudes on the Internets! they say that is only good way for kernel development and this is only way we can find enough vendor support to run it on those pesky x86 machines we have almost 0 drivers. and we also think we should remake kernel to be micro - that will show them that we mean business"

humor us, just write your API/ABI proposal on LKML and not forget to add that entire kernel API should be like this, because it shows quality and stuff. i would really like to read some replies.

PS: and don't start that "officially supported", "discontinued", "this is third-party fault" on me or whatnot. you talking about different models, that are performance results of those models in action.
but they, probably, _just didn't tested my case_, riiight ?

Great really, few examples to suit every case right? As if the FOSS stuff was tested thoroughly, just go back to read that piece of Torvalds on DRM. Or look at the oh so great Intel driver mess, crippling their already crippled hardware even more and then you see guys argueing "just use an old kernel then" or "those features aren't needed anyway", yeah say the people having different hardware. And reality check for you, this driver is all FOSS, and many years ago all the people hailed Intel for their great work as it "just works", now it doesn't anymore.

And if you did not know, there are merge windows now already, so if you had such a great change you could get a "no merge window now, so screw you".

It is funny that toolkits provide a stable API and there it is good and accepted, but please don't do something like that anywhere else. And the same time -- as was mentioned -- hardly any distribution is using the vanilla kernel and when there are bugs it's always the downstream's fault.

Btw. I am no kernel dev so I would be the last one to do such a proposal, that does not mean though that it would not have a lot of good aspects as well but you are only talking about black and white here, as if things were that easy.

[DebianAroundParis]

Btw. I am no kernel dev

Thank you for admitting you are incompetent.

Now try to learn to shut up when you are incompetent!

[mat69]

Thank you for admitting you are incompetent.

Now try to learn to shut up when you are incompetent!

Thank you for admitting that you are an idiot.

[pingufunkybeat]

I detect that the folks on the LKML may be aware of this situation, and if so, it sounds like they are just advocating good software architecture / design for its own sake. I think this is insanely stupid and pointless. Having beautiful software with ideal layering, coupling and object orientation is a waste of everyone's time if the software is untested crap. The purpose of writing software is not to produce code that's aesthetically pleasing to look at / contemplate; the purpose of writing software (especially device driver software) is to produce a resulting executable that does what the user (or applications acting on behalf of the user) expects.

Actually, you're missing the maintenance and porting. The hardware will still have to be used many years after the code was written and tested, and there are many changes which will happen during this time.

Properly written code is easier to maintain, and easier for new people to pick up after the original author disappears.

So if you are going to try and tell me that Gallium3d is a better driver than the proprietary alternatives (even fglrx at this point), you're out of your mind. Gallium3d fails at its core mission, assuming that the core mission is to produce a high-performance, hardware-accelerated 3d graphics device driver that is able to stably and reliably support the state-of-the-art graphics APIs. It's slow, almost completely untested (if you take into account all the countless possible code paths that have never been executed before), and it doesn't support APIs that have been around for several years.

Sorry, but Gallium3d is extremely new. It hasn't even had the chance to fail yet. In the short time since it has been introduced, it has shown to be FAR easier to develop for than the traditional Mesa way, and the progress on Gallium drivers has been incredibly fast given the small number of developers.

Its core mission was to improve code re-use and to help new developers get involved. It has succeeded at both of these, and most of the exciting new developments (video decoding, computing, new features, etc.) have only started appearing in the free drivers after the switch to Gallium3d.

Face it: the cathedral model of device driver development is kicking the bazaar's ass right now. We are too obsessed with getting a common infrastructure that "looks pretty" and generalizes concepts / facilities that support all conceivable hardware now and for the next 10 years. Instead, we need to borrow a little wisdom from the proprietary folks, and get things to just work.

It's easier to get things to "just work" when you have 500 full-time programmers on your payroll writing a driver with no worries about any legal issues.

You're comparing the work of a few hobbyists and a couple of paid programmers over 3 years to the work of 300+ full-time programmers over 15 years.

This is clearly a bogus comparison. Pay 300 developers to develop for Gallium3d full time and then we'll compare.

Sorry for this long rant, but I just don't see how trying to further generalize our driver architectures to be universal enough to support multiple operating systems is going to improve the actual situation with the lack of features/performance in drivers. It's basically an academic exercise with no practical utility.

Many of the new features were simply not possible without a major redesign of the 3d driver model. You couldn't do OpenGL 2 with the old driver model of Mesa, period.

[V!NCENT]

Windows doesn't have 99% marketshare anymore on desktops and they lost almost all of their marketshare in the mobile market by removing all backwards compatibility in Windows Mobile 7. Just saying.

Now a common hardware architecture among all operating systems would be good for both the companies paying for driver development and for Linux HW compatibility list.

Having wrappers might be even better for Linux, given not all smartphone companies release newer versions of Android and having proprietary drivers kills it for the customer; he/she has to by a new phone just for an Android update.

On the other hand this may lead to "Oh we can just make proprietary drivers for Linux.", while companies are currently more or less forced to GPLv2 it.

On one hand I like to have Android updates for the rest of my phone's life, but on the other hand I like that the world needs to bow for FLOSS.

But writing drivers for Linux first and then for Windows might not work.

[pingufunkybeat]

We have wrappers, and everybody hates them.

I don't think that they are the answer to anything.

[curaga]

@V!NCENT, how is Android relevant in that way? Any drivers in Android kernels have to be GPL already.

[DebianAroundParis]

Thank you for admitting that you are an idiot.

You REALLY believe you are more intelligent than everyone: kernel devs, people who dare contradict you,...why don't you create your own OS to prove the World you are the most competent man on this planet as far as operating systems are concerned? You sound so frustrated...

[mat69]

You REALLY believe you are more intelligent than everyone: kernel devs, people who dare contradict you,...why don't you create your own OS to prove the World you are the most competent man on this planet as far as operating systems are concerned? You sound so frustrated...

I never said anything of the above and looking at your first replay you are the one that sounds frustrated to me. Yeah it's okay, trying to put bullshit into other mouths. And you wonder why I called you idiot?

Just because I am not working on the Linux kernel does not mean that I am not entitled to have an opionion, that I am not entitled to talk about that opinion. If you aren't happy with that don't read my posts. And if there is so much wrong in my posts be free to correct them.

Regarding kernel devs, well those are human too and contradict themselves sometimes as well, so just because they/some say something does not mean that it is always "right" -- as if there was something like that -- and in fact I do _not_ imply here that it is wrong, just that you can shove your "shut up" up your ass.