XFree86 DRI on NetBSD
Dan writes "Erik Reid has been working on adding DRI support for NetBSD. Direct Rendering Infrastructure, also known as the DRI Project, is a framework for allowing direct access to graphics hardware in a safe and efficient manner. Some of Erik's work has been imported into XFree86 4.3.0 which is now in xsrc tree. He has subsequently put together a fairly large patch which compiles and works on his NetBSD/i386 1.6P system with a matrox g450. Try out the patch and give him some feedback!"
...what if anything this might mean for getting DRI on OpenBSD? Thanks.
Now give me nVidia and ATI drivers that have all the support/features under linux/BSD that you have under windows THEN I'll be exited.
Patrick Havens (Mr. 573333 to you.) Graphic Artist / Coder / Father / Journeler
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It
HURRRRR what's a NetBSD?
.
The Iraqi leader, and possibly his two sons, were said to be in a private house built over an underground bunker in southern Baghdad.
.
What happened next, one senior administration official said Thursday, ''has created one of the great mysteries of the first day of the war -- did we hit anyone and if so, who did we get?''
.
On Thursday night, officials were still holding out hope that one of the American 2,000 pound bombs and nearly 40 Tomahawk cruise missiles, each carrying 1,000 pounds of explosives, may have struck Saddam or one of his sons, Qusay and Uday.
.
''It may take days,'' the official said, ''to sift through it all.''
.
The mystery deepened as intelligence agencies monitoring Iraqi communications detected a significant drop in intercepted conversations among the top leaders of the country. Some officials speculated that Iraq's leadership had gone underground, others believed that, as one official put it, ''their phones melted.''
.
Either way, it was a surprise start to the war. It began close to 3 p.m. on Wednesday, when George Tenet, the director of Central Intelligence, got the tip that Saddam and his top leadership might be in the fortified bunker in Baghdad.
.
Tenet raced to the Pentagon to discuss the information with Secretary of Defense Donald Rumsfeld and his deputy, Paul Wolfowitz, then spoke to General Richard Myers, the chairman of the joint chiefs of staff.
.
''There was no question about the legality of the target, but there was some discussion about how solid the information was and who might actually be there and when,'' said a senior official. ''The conclusion was that even though we didn't know for sure, it was an important target in any case.''
.
General Tommy Franks, the commander of allied forces in Iraq, had already begun planning a strike with Tomahawk cruise missiles against the bunker, the official said, and ordered the F-117A fighter jets aloft in preparation to strike -- even before Bush signed the attack order.
.
Franks, who was at his forward command post near Doha, Qatar, had the same intelligence information from CIA. officers in the field that Tenet was giving Rumsfeld, the official said.
.
Around 3:30 p.m., Tenet and Rumsfeld carried the information to a meeting with Bush and his top national security officials in the Oval Office. For three hours, the group discussed the source of the information, how likely it was to be true, and the risks of the operation. They spoke to Franks and came to the decision, the official said, that Tomahawk cruise missiles alone would not destroy a bunker that intelligence showed was buried under layers of dirt and concrete.
.
Assembled for the discussion about the attack was Bush's war council: were Vice President Dick Cheney, Rumsfeld, Secretary of State Colin Powell, national security adviser Condoleeza Rice, White House Chief of Staff Andrew Card Jr., and General Richard Myers of the air force, chairman of the joint chiefs of staff. The group concluded that it was imperative to send the F-117s, which can carry ''bunker buster'' bombs, a much heavier payload than a cruise missile.
.
According to senior government officials, Bush listened impassively as his top aides debated what might be done, weighing, as minutes ticked by whether to stick with the meticulously scheduled opening of the war with the extraordinary possibility that the United States could land a potentially lethal blow against the Iraqi regime.
.
''This was the end of the 48-hour period for Saddam to get out of Iraq,'' said one official. ''So to have at that very moment when you're considering starting a conflict, to have a fairly good idea of knowing where senior most leaders are, is a pret
Just like QT unifies the different window systems and opengl unifies various graphic systems, I think we seriously need a unified system of drivers for all *nix including Linux, BSD, Solaris if Sun sees the potential, AIX ditto, Beos and darwin. Newer OSes like Plan9 would use the infrastructure and gain support of ALL the hardware.
I'm not too sure how we could cope with not adding additional code layers slowing things down.. perhaps an M4-based system that changes the right functions in the driver code, and removes or replaces OS-specific functionality depending on the output of uname. Such a unified system would attract hardware designers who would release their driver code according to this structure to support multiple OSes, and Free Software would be the big winner here.
Ive had to move from FreeBSD to Linux to Solaris now, due to the inherent lack of tokenring drivers, or its stability. FreeBSD had only one TR supported, in alpha, and it crashed. I wish I had the option of using NetBSD. Linux has a slew of TR supposedly supported but there are some bugs in receive buffers of TR code when using it with ethernet and ipfilter. I tried tuning many things, even tried to implement my own receive buffer with additional checks. It was a bit complicated for me.
The various unixen have a collection of kernel hooks that could be used in drivers. A simple large table could be made for hooks that are similar, showing differences in naming, arguments and limitations of buffers etc. Other pointer hooks then could be made to represent and encapsulate these hooks, also encapsulating additional procedures that need to be run before/after each hook on specific systems.
Non-equivalent hooks are more difficult to use, some might need additional programming on some systems while other systems would have part of that functionality built in. For this, we gotta build trees of functionality of each driver type, say networking, graphic, input etc, for each system making a 3d graph of the functionality and working with the weaknesses of some systems making it similar to the strengths of others, makin it easy to create encapsulating hooks.
The encapsulating hooks themselves could be either C functions, pointers, or M4 macros, which would be replaced with the code of the right system just before compile time. I would go with c pointers if theres NO resulting performance hit after being compiled with gcc -O2. If theres a resulting performance hit on ANY system, I'd say we're pretty much stuck with M4 which on some systems could become too complicated to be worth it.
Pulling out all drivers from the Linux code, and FreeBSD and sticking it all into the tree, and demonstrating its working would be the end of the first phase. Establishing a proper standards group, quite possibly with posix/ansi/someotherbody would complete the second phase. After that its all sit back and wait, and just like WDM in windows, hardware makers should re-release driver codes for a more unified platform.
Apart from a major boost to Net/OpenBSD, Plan9 and others, the Linux kernel might be lightened much from todays 30MB+. Yet another issue would be driver signing and security unless the whole driver structure is downloaded with the kernel sources of each OS.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
I'll do it next week, I promise. I'm on a crappy :)
dialup connection right now so can't download. Besides,
getting new hard drive next week so I'll definately be
able to install NetBSD 1.6.1 next week
It hurts 'n' stuff.
http://www.projectudi.org/ Or existed, it seems like it hasn't been updated in a while.
I did some work in this, interesting environment. All drivers are source compatible across all conforming environments. If the environments have the same C ABI (say, they're all x86) then the drivers are binary compatible. Caldera actually made this their native DDI for OpenUNIX 8. There are environments for OU8, Linux, and FreeBSD, and some drivers out there. One cool thing is that the environment handles MP. All your functions are guaranteed never to be interrupted. Downside is, it's a very different environment from what you're used to, and it takes a while to get your head around.
As an aside, RMS doesn't like the environment because it makes it easier to release binary only drivers. Not only does it insulate youfrom DDI differences between platforms, but also between Linux kernel updates.
Seriously, the "BSD is dying" troll was fairly amusing in it's own trolly way at first, but it's getting really quite tired now.
Don't get me wrong, I enjoy sifting through the comments with Threshold -1, and I do I like a good AC troll now and again. But I at least like to make my trolls interesting, sarcastic, amusing, and most importantly, different.
Posting the same dumb troll over and over again is just plain dull and unimaginative. Try and find something new and unique to troll with.
Thankyou.
Interesting stuff.
Part of opensource developer psychology is exclusivity. Belonging to for instance the FreeBSD or Debian linux camp, and not developing something that contributes to the other camps especially the commercial OSes like Solaris. I think this would hinder the unified drivers. And like you said its a very different environment, its also an added layer, and what attracts developers to system/kernel/driver programming in the first place is the low level.
But I think theres a threshold beyond which people will contribute more. Project UDI will take effort to get there, including remaking previous-ly made drivers in UDI. Since Opensource OSes have much to gain from this, they should rally around this idea, especially the underdog OSes like NetBSD. I wouldnt expect Linux developers coming wholeheartedly.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Why are you so dead?
I don't know exactly... Open and Net are similar systems so maybe it will help. But are Open users even interested in this. They seem to be so security focused they don't even mind Mozilla not working... On the other hand what is the use on DRI on Net, somebody playing quake on Net? Maybe in the future we have 3D models living in every web page and DRI becomes essential...