som mal taky mensi rozhovor s panom rwatsonom ;-)


tu som sa pytal ako to vyzera s 5.4 release process

< rwatson> DanGer: I think we're about a month from RELENG_5 starting to get locked down for it.
< rwatson> DanGer: a schedule isn't posted yet, so it depends a bit on how things look.
< rwatson> DanGer: we're looking for 5.4 to both be more stable and faster, and it's been doing some of both but we need to
clear up a few specific todo list items, do measurement, etc.
< rwatson> DanGer: we also need to decide if some of the changes that have gone into 6.x but haven't been merged yet should be
merged.
< rwatson> DanGer: generally speaking, for merging changes, the lists for merging are maintained by the developers working on
the tasks. I'm pretty good about merging network stack changes (for example, a bunch of the TCP cleanups I've done
are already in RELENG_5) but others are less good. Also, some of them will be a question of carefully doing
measurements and stability tests.
< rwatson> DanGer: the 5.4 todo list should get fleshed out a lot in the next month or so leading up to the lock down.

a tu zas preco sa tolko zapodieval s cleanupom ipx v network stacku, kedze je to uz zastarale a malo pouzivane

< rwatson> DanGer: Having the network stack run without the Giant lock is something of an all-or-nothing sort of deal: it's
difficult to have some bits locked down, but not other bits. Right now, most of the stack is safe without Giant,
but there are some specific chunks that aren't (for example, IPX/SPX in RELENG_5). If that code is present in the
kernel, we have to run the whole stack with Giant.
< rwatson> DanGer: So I'd like to get the basic locking done for all parts of the network stack so we can remove the
infrastructure for running the stack with Giant.
< rwatson> DanGer: also, one of the things I like about netipx and netatalk is that they're relatively simple implementations
of the stack concept, whereas netinet and netinet6 are really complicated. This means it's much easier to test
ideas with them than to test them directly on netinet -- you can prototype them much faster.
< rwatson> DanGer: so I've found it quite useful to do the locking on ipx and appletalk because I can test other ideas while
doing it.
< rwatson> DanGer: besides, it turns out more people run IPX/SPX than you might think... :-)
< rwatson> DanGer: well, the basic locking work for netinet is largely done -- hence our being able to run it without Giant by
default. We run the input path for netinet6 under Giant since there are substantial sections of netinet6 that are
not yet MPSAFE enough.
< rwatson> DanGer: I did a moderate amount of cleanup on TCP in October November and that was largely marged to RELENG_5 in
December and January.
< rwatson> DanGer: netinet6 needs quite a bit more work, I think, but there are a couple of people actively looking at that.
< rwatson> DanGer: the other thing that really needs attention is netipsec -- Sam Leffler's FAST_IPSEC is fine without Giant,
but the KAME IPSEC code requires it.
< rwatson> DanGer: I'm still looking for a victim to work on that, or I'll do it but probably won't get to it for a couple of
months.
< rwatson> DanGer: the other dimmension for the netperf work is optimizing performance, which is an important part of the focus
right now.