[openbeosnetteam] Re: Kernel move... [LONG]

David wrote:
>> And I failed to see what a syscall() on a socket can do that a 
>> ioctl() can't, since socket *are* file descriptors too.
>
> You do realise what we are talking about when we use the term syscall right?
> Or do you mean sysctl()? sysctl is strange as it doesn't ever need an fd to
> operate.

My mistake, I made confusion with sysclt() here, yeah ;-)

I agree that calling syscalls looks simpler than having 
a libnet <-> network stack thin driver interfacing them.

However, doing this:
1) will break our current code design into parts
2) will need everyone here to play with newos kernel, which will slow down 
both energy and motivation at least to start (as it need yet another partition 
for yet another OS...). Please, remember we're net_kit members, not kernel kit 
members. People who want to play with the new kernel are in kernel kit too, but 
not all us are.
3) will break/need to fork the code for a potential R5 network stack 
replacement hope that, even if you, David, never want it, is expected by many 
others (I'm asked very often "when could we replace net_server with OBOS one?").
If OBOS take more time to reach R1 than expected (who knows when here, apart 
that it's not yet!?) or even fail, this stack may be of great value for BeOS 
users. 
4) will make harder for beta-testers of the new stack: testing against a very 
well-known stable OS is far more easy from user's point of view than against a 
new, not yet friendly NewOS kernel...
5) is not necessary at all to support this new kernel, as the current code 
design should work too, without [m]any changes. If it reveal itself more 
difficult to *port* the design to newos kernel than expected, we'll have still 
time to adopt a new design then, no?

>> So, let's take advantage of our new kernel advantage : dynamic
>> kernelland modules loading and unloading!
>> ;-)
>
> That's all the davnatge you see to having our own kernel. Damn.
> So we should just close it off from further improvement? How sad.

No, obvioulsy not. Fixing any broken select() kernel support come to my mind 
here, for example (hopefully, we won't have to).
But it's not because we have access to kernel code that we should 
modify it ASAP, all, right now. Or we'll have a huge and unstable kernel really 
soon. In fact, /me think we should all resist to this evil temptation ;-)

> Oh, so in your world we just ignore any improvements we can achieve by
> better integration as it may harm the stability. 
> hey, let's just have an immediate feature freeze and never touch the 
> kernel again. We'll add everything as kernel modules 
> (I mean they can't harm the kernel stability can they???) and that'll 
> be very great!

Stability a one of the best feature an kernel can provide, so yes, I ignore 
them until they prove themself stable enough, which is far easer to stress out 
if they can be seperated easily from the monolithic-part of the kernel.
Better != good.

And, yes, if the kernel code is stable, what we add to him via kernel modules 
will never harm the kernel code, only the user system stability who use these 
modules (let's say net_kit stack), who can be said "just remove these files 
here and there to disabled them". No need for them to rebuild a kernel image 
from code (kernel compile config hell, someone?), or download again this kernel 
image without the networking-only code builtin... 

> The things that go into the kernel proper are things that work and don't
> change. By having the sockbuf code and the code that deals with sockets (not
> the protocol stuff, just the sockets) we put code that is effectively
> "static" into a place where it shouldn't be changed much. We essentially
> lock it away and simply use it. The modules we create are then simpler and
> more straightforward and can be smaller and better "targetted" at their
> needs and uses. This seems like an excellent idea to me and has more appeal
> than than the ideas your putting forward.

What's wrong by putting them in a common network/core kernel module like we do 
today? We don't change them too. Better even, this support code is only loaded 
in memory on user system that actually *use* the network service, not on all 
system if they were builtin in the kernel...

-Philippe

Other related posts: