[ros-kernel] ReactOS 0.3.0 Release Plans (sorry long)

[art yerkes]

On Fri, 17 Sep 2004 07:56:18 -0700 (PDT)
Steven Edwards <steven_ed4153 at yahoo.com> wrote:

> Hi,
> --- Ge van Geldorp <gvg at reactos.com> wrote:
> > I know Art can speak for himself, and I know the above is not cast in
> > stone, but still I feel the need to say that I think the combination
> > you
> > made above is not very good. It means you (we) are imposing a
> > deadline
> > on work being done by someone else (Art). I'm fine with saying we
> > will
> > ship 0.3 when networking is usable, I'm also fine with saying we will
> > ship a release by the end of the year, but in my opinion we should
> > just
> 
> I agree if networking is not ready then 0.3 is on hold. I talked with
> Arty about it yesterday and he wants it to be ready before the end of
> the year so the idea here is just to make a list of things we need/want
> and try to break them out in to sub-tasks that we can all jump in on
> and try and knock out. If we can break things up in to small enough
> tasks or find the network projects that he does not want to do like TDI
> we will be better able to find more people to jump in on the networking
> bandwagon or find weekend coders for other small tasks.
> 
> To make it really clear, if Art or anyone else feels like we are
> pushing then I am sending the wrong idea. I just want to make it easy
> for us to get it done.

In my opinion we should ship 0.2.5 in January if networking isn't working
by then.  I haven't done a great job of breaking up the task for someone
else to work on or keeping others informed, but I hope to change that this
week.  I'm breaking off another large chunk as a userland library, which
should make working with it more approachable.  I'm also making good my
threat to simplify the rest of the guts of tcpip.sys in the process.  I
simply can't work any faster unless this code is within closer reach and
feels more manageable.

Currently, I have broken off the ndis interface as lan.sys, and added a
userland testcase for just that.  That should help with the nic testing
a lot since you'll be able to test just the ndis part with my nifty
program all from the comfort of the command prompt.

I'm on the last file of breaking off the stuff in drivers/net/tcpip
network into a separate, userland linkable library which i will write a
test case for similar to the one in apps/tests/oskittcp.  I didn't know
if i would need to break these off, but I do think it will speed things
up being able to use comfortable environment and better tools (valgrind!)
on them.  If somebody would like to finish this part, let me know.  It's
actually pretty mechanical work.  Writing the test app for this part
should probably be done by the same person, and should follow the same
model as the oskit test.

Once I have this part in place, I need to gut tcpip.sys and replace most
of it with the libraries i dished out of it, making it more of a glue
layer between several independent components.  The main part that will
still be complicated is the TDI interface.  I invite others to look at
tcpip/main.c and tcpip/dispatch.c and see if they can shake out any
obvious problems or see any more type mismatches and such.  Making this
code compile with -Wall and -Werror was an experience for sure but it
helped me find most of the remaining problems with the original code that
I had just stared at too long.

Somebody could help a lot by simplifying and verifying the datagram send
stuff in transport/datagram.  This code is confusing to me, and I think
it could be made much simplier.  In particular, I'm continually daunted
by calls to prepare and by what exactly the sizes and pointers in the
IP_PACKETs point to and measure.  Somebody who can make datastructures
with better names and simplify this code overall will make me happy.
I think I want to remove the send loop from here.  Eventually we can give
lan.sys the ability to keep the adapter jumping with a short queue, but
for now we can lean on TCP to do retransmission if an output packet is
not sent (at this point we're not likely to miss one).

We will want to simplify our ARP system so that it isn't as cosy with
routing for a number of reasons.  The first is simplicity, but equally
important are the need for media independence in the routing system and
the fact that the routing system does not need to know whether another
packet is in flight to the target or not.  What I envision is a simple
scheme which holds one packet per target for some fixed time, forwarding
ARP requests until either a reply or timeout happens, then releasing or
deleting the packet.  This code should be localized in ip/transmit.c.

Hopefully this provides some insight into where we are, where we're
going etc.
-- 
Hey, Adam Smith, keep your invisible hands to yourself!