These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.
No functional change.
designated initializers.
I have not built every extant kernel so I have probably broken at
least one build; however I've also found and fixed some wrong
cdevsw/bdevsw entries so even if so I think we come out ahead.
Leave a note about what this code probably should look like for
anyone who comes rummaging around with the intent to really fix it.
I would do that myself if I had time and resources to test this at
the moment, and more comfort with our firewire stack, but I don't.
This way, if anything fails, it just fails; you don't panic. This can
happen if suspending and resuming of firewire is broken (e.g., as I
encountered in PR kern/44581).
To make code in 'external' (etc) still compile, MALLOC_DECLARE() still
has to generate something of type 'struct malloc_type *', with
normal optimisation gcc generates a compile-time 0.
MALLOC_DEFINE() and friends have no effect.
Fix one or two places where the code would no longer compile.
When plugging a firewire webcam, sbp attaches.
sbpattach() calls sbp_alloc_target().
In sbp_alloc_target, crom_search_key() fails and sbp_alloc_target() returns NULL.
Move mutex and list initializations up in sbpattach() and in sbp_alloc_target()
so that destroyal of them through sbpdetach() does not cause
LOCKDEBUG panics when unplugging the firewire webcam.
fwohci0: BUS reset
fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode
panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file "../../../../ker
n/subr_kmem.c", line 195
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff8022db1d cs 8 rflags 246 cr2 0 cpl 6 rsp fffffff
f80fafb68
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x2ba
kern_assert() at netbsd:kern_assert+0x2d
kmem_alloc() at netbsd:kmem_alloc+0x18a
fwohci_intr() at netbsd:fwohci_intr+0xbe2
...
I will send-pr for the next one... Looks like someone did not use DIAGNOSTIC
when made the changes.
jakllsch