Heads up: IPX/SPX cleanup

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Sun, 2 Jan 2005 16:14:23 +0000 (GMT)
Yesterday and today I merged a fairly large outstanding cleanup to the
IPX/SPX code that I've been working on in preparation for making IPX/SPX
run MPSAFE.  This includes:

- Converting to using queue(9) macros for IPX PCB linked lists.
- Cleaning up, and where necessary, adding socket buffer locking.
- Cleaning up and fixing route locking.
- Fixing IPX and SPX to actually work with the newer revisions of gcc
  which pack structures differently, eliminating at least two sources of
  on-the-wire corruption.
- Fixing behavior of socket address calls on IPX sockets under low memory
  conditions.
- Dead code removal, in particular broken dead code removal.
- Annotation improvements.
- Style improvements.

The reason this is a "Heads up" and not a "HEADS UP" is that IPX/SPX
appears to have been sufficiently broken previously in 5.x/6.x that the
chances are good these changes can't have made it more broken, and likely
make it a lot less broken.  If you've previously been using IPX/SPX on
FreeBSD 4.x or earlier 5.x and ran into problems with 5.2 or 5.3, things
may well now work for you again.  I'd appreciate feedback from users of
IPX/SPX on FreeBSD as to whether this is the actually the case.  In
particular, if things seem to have gotten more broken than they were,
please let me know.  I'm not in a very good position to test interop with
other operating systems so assistance there would be helpful.

My intent is to merge a number of the critical fixes (structure packing,
route locking) to RELENG_5 in a couple of days, and then merge the more
infrastructural work in a couple of weeks.  IPX/SPX locking such that it
can run without Giant will probably follow on HEAD in a couple of weeks,
and RELENG_5 in a month or so.  I'm not currently in a position to work
with or otherwise test netncp or nwfs, so will have to look to others to
do that.  I will be committing a number of regression test tools developed
during this work for netipx sometime in the next few weeks, however, to
atempt to prevent regressions as described above from happening in the
future.

Thanks,

Robert N M Watson
Received on Sun Jan 02 2005 - 15:17:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC