Patch from Eric Norum <eric@…> to address the following problem
report from Philip A. Prindeville <philipp@…>:
I was working on a device driver for a certain ethernet chipset that
occassionally wraps in its buffer, and causes a resulting mbuf chain
with only a few dozen bytes in the first mbuf of the chain.
I wouldn't have thought this would be a problem, until I ran some
stress tests that flooded the ethernet receiver with packets and
started to get panics here:
250
251 if (m->m_pkthdr.len < sizeof(struct ip))
252 goto tooshort;
253
254 #ifdef DIAGNOSTIC
255 if (m->m_len < sizeof(struct ip))
256 panic("ipintr mbuf too short");
257 #endif
258
259 if (m->m_len < sizeof (struct ip) &&
260 (m = m_pullup(m, sizeof (struct ip))) == 0) {
261 ipstat.ips_toosmall++;
262 return;
263 }
264 ip = mtod(m, struct ip *);
and the panic was at line 256. But if I #undef'd DIAGNOSTICS,
then the m_pullup() at line 260 does the right thing and the packet
ends up being processed just fine.
So I started wondering, (a) why was the test checking for
something that apparently wasn't a fatal condition but rather
one that is subsequently recovered from a couple of lines later
and (b) why panic as a diagnostic "aid" from a recoverable
condition rather than just (say) log a message to the console?
All of this seems overly severe for no reason that is readily
apparent to me.

Changes from Ralf with script-19991021-0. He fixed the %files
issue and has mkbspspec in a better state. user.cfg is now
gone.
There are some miscellaneous changes to buildall done by Joel
to clean up the build process.

Working on being able to cut RPMs. It now appears that the process
is working mostly for sparc at least.
There is one major problem -- the current process generates a unique
source file per RPM when in fact all of the source files are nearly
the same -- it is only the spec part of the rpm which differs.
The new file mkbinutils_subpackage_version is an attempt to
address this. It does part of the job right -- one source file
produces multiple binary RPMs. BUT the end user can not produce
the resulting RPMS themselves from SRPMS unless they also
build all targets.