Compatibility

So Haiku will most likely use a new networking stack based on NetBSD code.

R5 net_stack compatibility is out of the question now. But will this mean there will also be BONE incompatibility? (and that there will be 3 versions of all networking programs on bebits?)

> So Haiku will most likely use a new networking stack based on NetBSD code.

FreeBSD.
And it’s not a new networking stack as our current is largely based on former BSD stack code, but modularized and, unfortunalty, lacking multithreading support.

> R5 net_stack compatibility is out of the question now.

Why?!
The planned FreeBSD stack port should change only the internal stack code and design, some internal libraries behavior but not public API nor ABI.
We achieved to support both BONE and R5 net_server API and ABI (modulo some bugs), I can’t see why we couldn’t achieve the same with another stack code ported…

> But will this mean there will also be BONE incompatibility? (and that there will be 3 versions of all networking programs on bebits?)

Nope. No way. I really don’t want to see that.
In fact, I want convergence to BONE compatibility, because of Zeta and POSIX Sockets API larger conformance compared to R5 net_server.

But in no case we want to introduce yet another stack incompatible API or ABI.

phoudoin wrote:
> R5 net_stack compatibility is out of the question now.

Why?!
The planned FreeBSD stack port should change only the internal stack code and design, some internal libraries behavior but not public API nor ABI.
We achieved to support both BONE and R5 net_server API and ABI (modulo some bugs), I can’t see why we couldn’t achieve the same with another stack code ported…

> But will this mean there will also be BONE incompatibility? (and that there will be 3 versions of all networking programs on bebits?)

Nope. No way. I really don’t want to see that.
In fact, I want convergence to BONE compatibility, because of Zeta and POSIX Sockets API larger conformance compared to R5 net_server.

But in no case we want to introduce yet another stack incompatible API or ABI.

Thanks for clearing that up - I was extremely confused when I read the post from Egregius yesterday, and was fairly certain none of that was true (about lack of compatibility) – especially with the accomplishments from the previous port effort…

And I also couldn’t figure out where this information had come from since I had been following the mailing lists pretty consistently…

phoudoin wrote:
<snip> We achieved to support both BONE and R5 net_server API and ABI (modulo some bugs), I can't see why we couldn't achieve the same with another stack code ported...

Phieuw! Thanks for clearing that up. Just checking.

umccullough wrote:
Thanks for clearing that up - I was extremely confused when I read the post from Egregius yesterday, and was fairly certain none of that was true (about lack of compatibility) -- especially with the accomplishments from the previous port effort...

And I also couldn’t figure out where this information had come from since I had been following the mailing lists pretty consistently…

Sorry for creating any confusion :slight_smile:

Obviously I’m not much of a coder, but I thought since BONE broke net_server compatibility (and required programs to be rewritten) I thought Haiku had to choose which one to support. And since there was going to be an entirely new stack, I thought that would mean it would be different from BONE as well, and thus break BONE-enabled programs. But this needn’t be of course, I now realise. I was kinda worried.

But are you guys sure Haiku will support both? Yesterday Michael Phipps wrote on the mailinglist:

Quote:
<snip>No, not at all. FEATUREWISE, R1==R5. Bugwise, we hope, R1 will be much better than R5. The only place that we really creeped features were places where we had a lot of lattitude (i.e. places where backward compatability were either not doable) and where it made no sense at all to implement something that is horribly bad (net_server).
Egregius wrote:
phoudoin wrote:
<snip> We achieved to support both BONE and R5 net_server API and ABI (modulo some bugs), I can't see why we couldn't achieve the same with another stack code ported...

Phieuw! Thanks for clearing that up. Just checking.

umccullough wrote:
Thanks for clearing that up - I was extremely confused when I read the post from Egregius yesterday, and was fairly certain none of that was true (about lack of compatibility) -- especially with the accomplishments from the previous port effort...

And I also couldn’t figure out where this information had come from since I had been following the mailing lists pretty consistently…

Sorry for creating any confusion :slight_smile:

Obviously I’m not much of a coder, but I thought since BONE broke net_server compatibility (and required programs to be rewritten) I thought Haiku had to choose which one to support. And since there was going to be an entirely new stack, I thought that would mean it would be different from BONE as well, and thus break BONE-enabled programs. But this needn’t be of course, I now realise. I was kinda worried.

But are you guys sure Haiku will support both? Yesterday Michael Phipps wrote on the mailinglist:

Quote:
<snip>No, not at all. FEATUREWISE, R1==R5. Bugwise, we hope, R1 will be much better than R5. The only place that we really creeped features were places where we had a lot of lattitude (i.e. places where backward compatability were either not doable) and where it made no sense at all to implement something that is horribly bad (net_server).

BONE broke a few net_server programmes. Very, very few - I’m using a net_server Firefox on BONE right now. You have to implement libnet and libnetapi emulated on top of the new stack - as Be did. Cloning BONE does NOT mean losing net_server apps, at all - Haiku could easily have a more compatible libnet/libnetapi than BONE 7a did.

Seems I misinterpreted the presence of BONE-enabled programs on Bebits.

Egregius wrote:
But are you guys sure Haiku will support both? Yesterday Michael Phipps wrote on the mailinglist:
Quote:
<snip>No, not at all. FEATUREWISE, R1==R5. Bugwise, we hope, R1 will be much better than R5. The only place that we really creeped features were places where we had a lot of lattitude (i.e. places where backward compatability were either not doable) and where it made no sense at all to implement something that is horribly bad (net_server).

I believe what Michael was talking about was not implementing net_server as the ONLY network stack interface – by implementing a more solid and reliable BONE-compatible stack, Haiku will be overcoming one of the major drawbacks and limitations of R5…

Also, keep in mind that BONE was not really part of R5, so when Michael says R5+ – this is one of the pieces he is referring to.