>Okay, I'm starting to feel mad to have both *boring* job days AND no CVS >access to OpenBeOS code repository, thanks to my company firewall policy :-( phillipe, if you use windows at work then try HTTPort http://www.htthost.com/ i was able to use it to http tunnel through a proxy server and checkout the Apache 2 sources. you can configure it to allow other computers to go through it as well, so your BeOS PC should have no issues if you run it on a windows PC and access it via BeOS or Linux or even Solaris. > >So, let's try to write the longest post on this ML ever... >:-) > >> We can now build ourselves as a kernel driver. [...] >> This is the start of allowing ourselves to be very cool and do >> all sorts of stuff, as well as simplifying our i/o with regard to >> running as a process. developing our own IPC so we could be >> running the net stack in one team while other teams used the >> services was looking like a PITA and would have been a performance >> drag in the extreme. So, the solution? >> >> Basically we'll build the stack in a series of pieces that live >> in the kernel. > >I can't agree more on this shift of stack design :-) this stuff is way above my ability but from what i have been reading it sounds good :-) > >> - socket driver - this will be built mainly from code that is already >> in place in net-server/net_server.c, albeit it'll be removed from >> there and added to a separate file that will build a simple socket >> driver. >> This is responsible for creating a /dev/net/socket entry and >> handling requests to/from that socket. > >Hum, nobody want to use my submitted (and commited to CVS) driver >net_kit/source/kernel/net_stack_driver.c?! >It does exactly what we need: a device driver wrapper between clients (via >libnet.so) and our future kernel-living network stack. will i need a "normal" BeOS 5.03 install to test this ? (ie not BONE) <snip> thanks peter