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!)
kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()
all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.
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.
- use driver name instead of device instance name in 'driver' field
- add 'get_businfo' callback to fill in 'bus_info' field instead of
hard-coding "USB"
- use the kernel version for the 'version' field instead of 1
- adapt pseye and uvideo drivers to changes in struct video_hw_if
- support interlacing with VIDIOC_G_FMT
- set V4L2_CAP_TUNER if driver implements the set_tuner/get_tuner
callbacks
- set V4L2_CAP_AUDIO if driver implements the set_audio/get_audio/enum_audio
callbacks
- add support for the following ioctls: VIDIOC_ENUMSTD, VIDIOC_G_STD,
VIDIOC_S_STD, VIDIOC_ENUMINPUT, VIDIOC_G_INPUT, VIDIOC_S_INPUT,
VIDIOC_ENUMAUDIO, VIDIOC_G_AUDIO, VIDIOC_S_AUDIO, VIDIOC_G_TUNER,
VIDIOC_S_TUNER, VIDIOC_G_FREQUENCY, VIDIOC_S_FREQUENCY
- in video_submit_payload(), fix support for signaling sample complete
using frame numbers
- new optional callbacks for drivers: enum_standard, get_standard,
set_standard, enum_input, get_input, set_input, enum_audio, get_audio,
set_audio, get_tuner, set_tuner, get_frequency, set_frequency
for drivers that don't provide enum_standard, get_standard, set_standard,
enum_input, get_input and set_input, the original stub implementations are
provided
authors want them to be. For the buffer ioctls, define new ioctls with
the 32 bit buffer sizes. For the format struct, define it as packed
so it is the same on 32 and 64 bit. (I might need to version this)
2. the mmapped buffers need to be page aligned, otherwise mmap(2) does
not work. Make it so.
All this makes my ricoh camera work with emul-linux and skype running on
amd64. Next is sound!
- Storing updated video format after user changes format
- Round up number of xfers queued to multiple of 8, due to ehci inefficiencies
- Remove random debugging line I slipped in earlier
