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!)
them back on. Also distinguish between WSDISPLAYIO_MODE_MAPPED and _DUMBFB -
we only need to turn the registers off in _DUMBFB mode when mapping all 8MB
of video memory.
- get rid of some redundant variables ( sc_*phys and sc_*base were essentially
the same )
- we don't access video memory directly anymore, so:
* no more need for byte order tests
* don't map video memory if we have a MMIO register aperture
* get rid of various bits of support code dealing with video memory
access
- use MMIO register aperture if available, turn off register blocks in the main
aperture if not in use, to avoid overlap with video memory on 8MB cards
- don't scissor off access to off-screen memory. How the hell did this work on
Rage II? Apparently Rage XL treats the scissor registers slightly different.
Now this works properly on 8MB and Rage XL boards like Sun's PGX64.
where it looks straightforward, and pci_aprint_devinfo_fancy in a few
others where drivers want to supply their own device names instead
of the pcidevs generated one. More complicated cases, where names
are composed at runtime, are left alone for now. It certainly makes
sense to simplify the drivers here rather than inventing a catch-all API.
This should serve as as example for new drivers, and also ensure
consistent output in the AB_QUIET ("boot -q") case. Also, it avoids
excessive stack usage where drivers attach child devices because the
buffer for the device name is not kept on the local stack anymore.
specifically tell a driver that bridges upstream forward PCI I/O (or
memory) transactions to the device." Only bus drivers have any business
modifying these.
It returns the bus id and allows userland (like Xorg) to create mapping
of ttyE? and bus id. For now only PCI is implemented.
First discussed with macallan@ then public on tech-kern@ and tech-x11@
- device_t-ify
- sanitize debugging #ifdefs
- deal with firmwares setting up modes using other clocks than #0
- get rid of sparc and macppc-specific code, use device properties instead
- while there, use alternate box drawing font if needed
devices. This stops machfb0 from trying and failing to attach as
console on my G4 PowerBook. Now, genfb0 will attach as console,
instead.
Apparently, Michael Lorenz made a similar change on the netbsd-4
branch, but it was never committed to -current.
mmap() code.
This and similar requests will be replaced Soon, but these two in
particular should be pulled up to netbsd-4, and to allow doing that
smoothly, we're first introducing the "issuser" version.
Discussed with and okay macallan@.
mrg