“Thanks to the work of one of the most active code contributors lately, Hugo Santos, Haiku is getting a generic FreeBSD network driver compatibility layer that will allow FreeBSD network drivers to be compiled and used in Haiku with few, if any changes. At the time of this writing, not only has Hugo committed the compatibility layer to the Haiku tree, but he has also succeeded in building two FreeBSD drivers (if_em/Intel Pro 1000 and if_le/PCNet) which are now capable of running in Haiku.”
I’m delighted to hear this as this move will mean many many people who have been unable to use the BeOS or Haiku due to lack of networking support will be able to use their hardware again! Hopefully this will have a trickle over affect when the number of people using the various Firefox and other internet application ports begin to submit bug reports, etc….
–bornagainpenguin
many many people who have been unable to use the BeOS or Haiku due to lack of networking support will be able to use their hardware again
I’m not sure this will be available for BeOS R5 as it did require several enhancements to the kernel directly in order to emulate some of the FreeBSD kernel behavior IIRC. I could be wrong, however, and maybe Hugo broke all that logic out into a separate code library instead.
On the other hand, it definitely is excellent news for Haiku, and now finally it looks like I may see my 3com cards working great in Haiku as soon as Hugo gets if_xl working!
Hopefully this will have a trickle over affect when the number of people using the various Firefox and other internet application ports begin to submit bug reports
Not sure that will help immediately – many of the stability issues preventing apps like Firefox from running well are still pending.
The biggest possible achievement that may bring huge amounts of porting progress and feedback would be the ability to build large projects *in* Haiku itself (for example, having the ability to self-host and build Haiku from within Haiku would be a major step in this direction). This, however, looks like it may still be a ways off as the kernel probably requires quite some work yet before this will be a reality.
I’m hoping it’s the latter. Hacking the kernel to emulate FreeBSD behavior sounds “bad”. I see this as more of a temporary step to get basic networking up and running for a large amount of people in the short term, while driver developers work on doing ports to native drivers for Haiku. I don’t like the idea of hacking something to death just to have a quick “fix”.
Perhaps I’ll stop by tonight and see if Hugo is around to ask.
I do agree with your comments about native builds inside of Haiku. I really do think, however, the network functionality is what was holding back a larger number of people from using Haiku. I know it’s what has kept me from actively using it.
The stability fixes and such should be “helped” along once people start testing the system in more numbers. HOPEFULLY more developers will jump on board as well, to help with the additional bug reports/feature suggestions.
Haiku really needs some firm marketing direction now, that’s the one thing they are sorely lacking. They keep having really impressive breakthroughs/milestones, but the only reporting is ad-hoc. I haven’t seen any push for developers either, and that’s what they REALLY need.
Edited 2007-05-09 23:59 UTC
umccullough wrote:
I could be wrong, however, and maybe Hugo broke all that logic out into a separate code library instead.
ormandj wrote:
I’m hoping it’s the latter. Hacking the kernel to emulate FreeBSD behavior sounds “bad”.
It was the latter – I was confused because at least one change was made to the kernel and then apparently undone shortly afterward in the interest of NOT changing it.
So everything is bundled up in a compatibility library that the drivers link against! Neat
Haiku really needs some firm marketing direction now, that’s the one thing they are sorely lacking.
I have to disagree here I’m afraid. AFAICT there is a big demand, this very instant, for Haiku. this demand surpasses any number of people actally using BeOS by far. So marketing would be at a later stage I’d say
I was more specifically talking about marketing to developers.
I don’t see that many devs flocking to Haiku at the current point in time.
Nice work, keep it up.
Great stuff. It is so encouraging to see such progress pushing forward. Thanks!
The drivers will be native to Haiku, Just not using the Haiku specific API’s directly (A FreeBSD compatibility layer..)
But the code will be compiled as native Haiku binaries.. The compatibility layer probably itself uses the correct internal API’s.
But I agree this is just to get things off the ground, Hopefully they can eventually stop using the layer.. It just saves time while they work on more important parts of the kernel. (Without having to worry about drivers..)
Edited 2007-05-10 01:02
That’s just a naming issue but I wouldn’t call a driver developed for FreeBSD ‘native to Haiku’ even if it is compiled inside the Haiku kernel.
Anyway as long as a driver works, and as there shouldn’t be too much performance impact in this case, nobody care which API the driver used..
http://haiku-os.org/news/2007-05-08/haiku_getting_a_freebsd_network…
Go Hugo Go!
This is awesome news. I think driver wrappers are the way to go, at least mid-term. Given how small the Haiku developer team is, it’s much better if they spend their time writing code that makes Haiku stand out than writing hundreds of drivers. Wrappers that support foreing binary drivers are probably the only way to support certain kinds of hardware anyway (serious 3D graphics cards, certain WLAN chipsets).
Wrappers that support foreing binary drivers are probably the only way to support certain kinds of hardware anyway
Don’t make any mistake here – this is not a layer to support binary drivers – it requires recompiling (and possibly modifying) the FreeBSD driver source in the Haiku build environment.
Great Work Hugo! (And of course all other Haiku devs).
This is just clever.
Can’t think anything else to say besides “amazing news!”.
Haiku is getting closer and closer every day… I’m amazed with the latest results! =]
Stuff like this is why developers shouldn’t sign DNDs to get access to device specification so they can create drivers is a bad idea.
Releasing specs to all developers means that a device can be easily supported by all operating systems.