Remove unnecessary <sys/malloc.h>.

sun4v: Ignore spurious ldc CTRL/ACK/VERS messages (do not reset the connection anymore). Fixes occationals stalls when vdsk uses the ldc service. Observed on both T2000 and T5 host systems

branches: 1.6.10;
convert more KM_NOSLEEP to KM_SLEEP and remove code to handle failures.

in many device attach paths, allocate memory with KM_SLEEP instead of KM_NOSLEEP
and remove code to handle failures that can no longer happen.

Rename min/max -> uimin/uimax for better honesty.

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!)

branches: 1.3.12; 1.3.14; 1.3.16;
sun4v: Fixed PR 51554 - Avoid unsafe allocation in ldc/vdsk

branches: 1.2.2; 1.2.4; 1.2.6;
Avoid "cast to pointer from integer of different size" warning on
32-bit kernels.

sun4v: vdsk and ldc drivers - from OpenBSD, but heavily adapted to NetBSD scsipi - access to a virtual disk served from a ldom primary domain now works

sun4v: Ignore spurious ldc CTRL/ACK/VERS messages (do not reset the connection anymore). Fixes occationals stalls when vdsk uses the ldc service. Observed on both T2000 and T5 host systems

convert more KM_NOSLEEP to KM_SLEEP and remove code to handle failures.

in many device attach paths, allocate memory with KM_SLEEP instead of KM_NOSLEEP
and remove code to handle failures that can no longer happen.

Rename min/max -> uimin/uimax for better honesty.

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!)

branches: 1.3.12; 1.3.14; 1.3.16;
sun4v: Fixed PR 51554 - Avoid unsafe allocation in ldc/vdsk

branches: 1.2.2; 1.2.4; 1.2.6;
Avoid "cast to pointer from integer of different size" warning on
32-bit kernels.

sun4v: vdsk and ldc drivers - from OpenBSD, but heavily adapted to NetBSD scsipi - access to a virtual disk served from a ldom primary domain now works

convert more KM_NOSLEEP to KM_SLEEP and remove code to handle failures.

in many device attach paths, allocate memory with KM_SLEEP instead of KM_NOSLEEP
and remove code to handle failures that can no longer happen.

Rename min/max -> uimin/uimax for better honesty.

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!)

branches: 1.3.12; 1.3.14; 1.3.16;
sun4v: Fixed PR 51554 - Avoid unsafe allocation in ldc/vdsk

branches: 1.2.2; 1.2.4; 1.2.6;
Avoid "cast to pointer from integer of different size" warning on
32-bit kernels.

sun4v: vdsk and ldc drivers - from OpenBSD, but heavily adapted to NetBSD scsipi - access to a virtual disk served from a ldom primary domain now works

in many device attach paths, allocate memory with KM_SLEEP instead of KM_NOSLEEP
and remove code to handle failures that can no longer happen.

Rename min/max -> uimin/uimax for better honesty.

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!)

branches: 1.3.12; 1.3.14; 1.3.16;
sun4v: Fixed PR 51554 - Avoid unsafe allocation in ldc/vdsk

branches: 1.2.2; 1.2.4; 1.2.6;
Avoid "cast to pointer from integer of different size" warning on
32-bit kernels.

sun4v: vdsk and ldc drivers - from OpenBSD, but heavily adapted to NetBSD scsipi - access to a virtual disk served from a ldom primary domain now works

Rename min/max -> uimin/uimax for better honesty.

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!)

branches: 1.3.12; 1.3.14;
sun4v: Fixed PR 51554 - Avoid unsafe allocation in ldc/vdsk

branches: 1.2.2; 1.2.4; 1.2.6;
Avoid "cast to pointer from integer of different size" warning on
32-bit kernels.

sun4v: vdsk and ldc drivers - from OpenBSD, but heavily adapted to NetBSD scsipi - access to a virtual disk served from a ldom primary domain now works

sun4v: Fixed PR 51554 - Avoid unsafe allocation in ldc/vdsk

branches: 1.2.2; 1.2.4;
Avoid "cast to pointer from integer of different size" warning on
32-bit kernels.

sun4v: vdsk and ldc drivers - from OpenBSD, but heavily adapted to NetBSD scsipi - access to a virtual disk served from a ldom primary domain now works

branches: 1.2.2; 1.2.4;
Avoid "cast to pointer from integer of different size" warning on
32-bit kernels.

sun4v: vdsk and ldc drivers - from OpenBSD, but heavily adapted to NetBSD scsipi - access to a virtual disk served from a ldom primary domain now works