Please note that, this is currently considered as an
experimental feature so there could be some rough
edges. Consult http://wiki.freebsd.org/TMPFS for
more information.
For now, connect tmpfs to build on i386 and amd64
architectures only. Please let us know if you have
success with other platforms.
This work was developed by Julio M. Merino Vidal
for NetBSD as a SoC project; Rohit Jalan ported it
from NetBSD to FreeBSD. Howard Su and Glen Leeder
are worked on it to continue this effort.
Obtained from: NetBSD via p4
Submitted by: Howard Su (with some minor changes)
Approved by: re (kensmith)
- Remove unnecessary timestamps.
- Return CAM_RESRC_UNAVAIL for ORB shortage.
- Fix a lock problem when doorbell is used.
- Fix a potential bug for unordered execution.
'result' is still NULL and we do not need to free anything.
That allows us to gc the entire goto parts and a now unused variable.
Found with: Coverity Prevent(tm)
CID: 2519
do not continue with a NULL pointer. [1]
While here change the return of the error handling code path above.
I cannot see why we should always return 0 there. Neither does KAME
nor do we in here for the similar check in all the other functions.
Found with: Coverity Prevent(tm) [1]
CID: 2521
114 bytes of cmos ram in the PC clock chip. The big difference between
this and the Linux version is that we do not recalculate the checksums
for bytes 16..31.
We use this at work when cloning identical machines - we can copy the
bios settings as well. Reading /dev/nvram gives 114 bytes of data but
you can seek/read/write whichever bytes you like.
Yes, this is a "foot, gun, fire!" type of device.
without an mtag in ipsec4_common_input_cb.
So in case of !IPCOMP (AH,ESP) only change the m_tag_id if an mtag
was passed to ipsec4_common_input_cb.
Found with: Coverity Prevent(tm)
CID: 2523
handle, document those sprotos using an IPSEC_ASSERT so that it will
be clear that 'spi' will always be initialized when used the first time.
Found with: Coverity Prevent(tm)
CID: 2533
- In tdq_choose() only assert that a thread does not have too high a
priority (low value) for the queue we removed it from. This will catch
bugs in priority elevation. It's not a serious error for the thread
to have too low a priority as we don't change queues in this case as
an optimization.
Reported by: kris
thinking it had the whole chunk. This could cause a crash if
a large packet drop came in. Fixed by adjusting the trunc length
down to the limit.
- Large sacks with lots of segments could also have same issue. Changed
duplicate and segment handling to use proper get_m_ptr function to
pull each block from mbuf chains.
priorities, etc.) in the NICE field:
Use a combination of pri_native and pri_user instead of pri_level to
guess the original realtime priority. Using pri_level here has been
wrong since 2001/02/12. Using only pri_native here would be correct
if the kernel actually initialized it reasonably. (The kernel exports
its raw td_base_priority as pri_native, but userland mostly wants a
refined base priority). Give up on waiting pri_native to work correctly
and only use it when there is nothing better (for kthreads).
This should reduce printing of bizarre pseudo-nice values. Bizarre
values are still printed if we observe a transient borrowed priority
for a kthread (transient borrowing is the main thing that makes the
raw td_base_priority almost useless in userland), or if there is a
kernel bug. One current kernel bug involves the kernel idprio thread
pagezero permanently changing its priority from PRI_MAX_IDLE (255) to
PUSER (160). Then the bizarre value "ki-6" is printed instead of
"ki31". Here "-6" is PRI_MIN_IDLE - PUSER = -64 truncated to 2
characters. We are observing a transient borrowed priority that has
become permanent due to a bug.
ps/print.c:priorityr() needs similar changes (including ones in stage 2
here).
