at the credential to be used by the connection. However, the pointer's
value was ignored when actually setting hcp->nc_owner.
(1) Do set nc_owner to the owner pointer value so that the credential is
not discarded after being carefully configured.
(2) In the case where we create a new credential with modified uid, copy
the existing credential to initialize non-uid fields to existing
values, which will lead to a fully initialized MAC label, groups, etc.
Found with: Coverity Prevent(tm)
CID: 2226
the card, panic explicitly if EN_DEBUG is enabled. In the (default)
case of !EN_DEBUG, the driver resets the card. Probably this case
shouldn't exist at all.
debug is turned off, initialize locks with NOWITNESS flag.
At some point I'll get back to them, we would probably need BLESSING
functionality, which is currently turned off by default.
SD Simplified specification, as well as other SD and SDIO
implemenations I've examined, suggest this disclaimer may be required.
It is unclear to me exactly what the license would be for, or why it
might be required. Err on the side of caution and include this
disclaimer so anybody deploying this code can judge for themselves. I
have no further unformation about the details.
parent vnode and relock it after locking child vnode. The problem was that
we always relock it exclusively, even when it was share-locked.
Discussed with: jeff
clusters. This helps quite a bit on my low end machines (improves
performance by about 300Kpps when being blasted by a hardware
packet generator).
- Include one extended f/w counter forgotten in earlier commit
Sponsored by: Myricom Inc.
change the way of what ppp submits to the RADIUS server
as NAS-Port-Id. Possible options are: the PID of the process
owning the corresponding interface, tun(4) interface number,
interface index (as it would get returned by if_nametoindex(3)),
or it's possible to keep the default behavior. Check the ppp(8)
manual page for details.
PR: bin/112764
Submitted by: novel (myself)
Reviewed by: flz
Approved by: flz
MFC after: 1 month
- upgrade to reflect state of 1.0.0.86
- move from firmware rev 3.2 to 4.0.0
- import driver bits for offload functionality
- remove binary distribution clause from top level files as it
runs counter to the intent of purely supporting the hardware
MFC after: 3 days
back in a simulated resume instead of entering the requested suspend state.
This helps in testing drivers separately from the acpi suspend code. To
test your drivers, set debug.acpi.suspend_bounce=1 and then run
acpiconf -s3 (or 4).
MFC after: 1 day
are installed twice (once in non-widec version, onec in widec version).
Headers with widec enabled are compatible with non-widec version
for libraries. However, if you do a repeat build/install, the curses.h
is always overwritten. The reason is that headers and statics libraries
are installed with -S option to preserve their mtime if no actual changes,
which saves time when doing incremental builds. The curses.h is installed
by non-widec ncurses first, then by widec ncurses. So next time, it happens
again. You see something like this:
# pwd
/usr/src/lib/ncurses
# make -s installincludes INSTALL="install -v"
===> ncurses (installincludes)
install: curses.h -> /usr/include/curses.h
===> ncursesw (installincludes)
install: curses.h -> /usr/include/curses.h
# make -s installincludes INSTALL="install -v"
===> ncurses (installincludes)
install: curses.h -> /usr/include/curses.h
===> ncursesw (installincludes)
install: curses.h -> /usr/include/curses.h
The solution is to disable installing headers in non-widec version. Now
you see this:
# pwd
/usr/src/lib/ncurses
# make -s installincludes INSTALL="install -v"
===> ncurses (installincludes)
===> ncursesw (installincludes)
# make -s installincludes INSTALL="install -v"
===> ncurses (installincludes)
===> ncursesw (installincludes)
For form/panel/menu libraries, the headers are the same for both version.
To be consistent with ncurses, I also disable the installation in non-widec
version.
Reported by: des
Reviewed by: ru
Thanks to: ru
Approved by: delphij (mentor)
MFC after: 2 weeks
compiler invocation. This is just to help get over the hump of people
tracking down bugs that may cross the GCC 4.2 upgrade.
It is envisioned that this option goes away after a suitable amount
of time.
