if the probe succeeds. This guarantees that the BSD scheme
wins over the MBR scheme when MBR gets to probe first. Build-
or link-time conditions can cause schemes to end up in the
linker set in a different order. Normally BSD is before MBR
in the linker set and as such get to probe first. But typically
when the kernel gets rebuild or relinked, this can change.
- Document the minor(3), major(3) and makedev(3) macro's. They also
apply to umajor() and uminor() in the kernel, but hopefully we'll sort
that out one day.
- Briefly dev2unit() inside the make_dev(9) manual page, since this is
now the preferred macro to obtain character device unit numbers inside
the kernel.
- Remove the device_ids(9) manual page. It contains highly inaccurate
information, such as a description of the nonexistent major().
sys/param.h and move the MI numbers out of here. Also move the MI
defines. Also remove a couple defines not in use (not sure if it is
age, or OpenBSD origins for thse). Note the current values that are
overrides that appear to be odd in some way.
More cleanup could be done here: NBPG appears to be spelled PAGE_SIZE
these days. There's new ways to spell PGOFSET and PGSHIFT too, I
think. These constants duplicate the MI constants and are sprinkled
into the mips code only. Further investigation is needed.
all to date and the latter also is only used in ia64 and powerpc
code which no longer serves a real purpose after bring-up and just
can be removed as well. Note that architectures like sun4u also
provide no means of implementing IPI'ing a CPU itself natively
in the first place.
Suggested by: jhb
Reviewed by: arch, grehan, jhb
Because we now enforce UNIX98-style PTY's, we now use a lot of TTY's
that don't have the traditional /dev/ttyXX naming scheme. pkill(1)'s -t
flag automatically prepended the word "tty" to each TTY that was passed
on the command line. This meant that `pkill -t pts/0' was actually
converted to /dev/ttypts/0. Disable this broken behaviour for now.
Reported by: erwin
former more explicitly tells the compiler that you want an empty loop.
There are some lint programs that use this hint to avoid generating
warnings.
No functional change...
JBus to PCI 2.2 bridges. In theory, this driver should also handle
`XMITS' Fireplane/Safari to PCI-X bridges but due to lack of access
to such hardware, support for these hasn't be fleshed out, yet.
that a nested partition (typically the BSD disklabel)
is not done tasting while the root file system is being
mounted. While this is rare, it's still possible.
in the transmit path, such as TCPS_TIMEWAIT, fail the credential
extraction immediately rather than acquiring locks and looking up
the inpcb on the global lists in order to reach the conclusion that
the credential extraction has failed.
This is more efficient, but more importantly, it avoids lock
recursion on the inpcbinfo, which is no longer allowed with rwlocks.
This appears to have been responsible for at least two reported
panics.
MFC after: 3 days
Reported by: ganbold
that DTrace uses.
This fixes a bug that would have affected kernels built with MAC and all
kernels built after the mpsafetty integration.
The bug will be apparent in RELENG7 on MAC kernels.
Reported by: kan
and Xlazypmap differ from the frame for Xtimerint. The Xtimerint puts
pointer to the frame between return address and frame body, while rest
of the functions listed above do not. Correct offset calculation to
allow the ddb backtrace to step over such frames.
Noted and reviewed by: tegge
Tested by: pho
MFC after: 1 week
setting TDF_INPANIC then it will never be rescheduled again. Wrap
setting the panic condition with the critical section.
Noted and reviewed by: tegge
MFC after: 1 week
The uminor() and umajor() functions have the same use in kernel space as
the minor() and major() functions in userspace. If we ever get rid of
the minor() function in kernel space, we could decide to just expose
minor() and major() to kernel space, making uminor() and umajor()
redundant.
There are two reasons why we want to have uminor() and umajor() in
<sys/types.h>:
- Having them close together prevents them from diverting. Even though
it's unlikely the definitions will change, it's a good habit to have
them at the same place.
- They don't really belong in kern_conf.c. kern_conf.c has been
liberated from dealing with device major and minor number handling.
The device_ids(9) manpage now lists the wrong #include's, because it
should only list <sys/types.h> now. I'm leaving it as it is now, because
I wonder if we should document them anyway. We're probably better off
documenting minor(3) and major(3).
