Re: arp called for own IP address and 2.0.30

Eric.Schenk@dna.lth.se
Fri, 20 Jun 1997 00:03:30 +0200


Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>There is a bootp client and that combined with NFS root happens to be
>useful to many. We also need to get that to work in 2.1.x. Possibly the
>right answer however will be to put the magic _in_ the bootp client
>and use a SOCK_PACKET socket. That keeps it out of kernel space.

I thought the bootp client/server stuff was working in 2.1.x if you
turned on the right routing options in /proc/sys/net/ipv4????

In any case, the comment about SOCK_PACKET reminds me, we should
nail down the intended semantics of the SOCK_PACKET interface in writing.
I've had to extend the implemented semantics a bit to get the
packet shell working, and I think now would be a good time for this.
Alan, are there any existing notes about this, or should I just
start writing?

>The other thing we have to do before 2.2 is put the IP code on a diet. Its
>expanded about 50K from 2.0 to 2.1.43 and the increase in functionality
>isnt very high for most people

I just took a look at where the new "fat" is. The major offenders are:

pre-2.0.31 2.1.43 (growth)
tcp 28345 36092 7747
routing 7349 30599 23250

The routing code includes the new fib and ipmr implementations,
accounting for most of the growth in the routing material.
We also still have the PIM code to add, which will increase this
a bit more. A lot of this is new functionality.

There is some further growth in most every object file in the ip layer,
with the exception of masquerading, which has not been updated in
the 2.1 series, but has seen updates recently in the 2.0.30 kernel.
(Which means the growth is a little worse than it looks by just
comparing the size of the object files.)

I'm not sure what we can do to slim down the routing code, if anything,
but Alexy is the person to be talking about that.

For the tcp code, and the ip code proper, David and I have written
up an action plan for rewriting that we think will slim it down and
make it faster as well. We'll see how well it works once we can start
cutting fresh code.

The persistent small growth in the remaining files should be examined to
see where it comes from.

-- 
Eric Schenk                               www: http://www.dna.lth.se/~erics
Dept. of Comp. Sci., Lund University          email: Eric.Schenk@dna.lth.se
Box 118, S-221 00 LUND, Sweden   fax: +46-46 13 10 21  ph: +46-46 222 96 38