- Constify structure members that should not be changed
during process.
- Apply static where needed
- signed/unsigned madness
- Bump WARNS?= levels from 2 to 6
(this is a diff reduction for a subsequent commit against these
Makefile's)
any pending RADIUS transaction. Use this before sending RAD_STOP RADIUS
messages so that we definitely ``stop'' the session.
It was discovered that sometimes when the link timed out, we got lucky
enough to have an un-ACK'd RADIUS accounting transaction in progress,
resulting in the RAD_STOP message failing to send.
Original report found on: A russion news group
Text translated by: glebius
Tested by: Alexey Popov llp at iteranet dot com
MFC after: 7 days
mmap() on NTFS files was hosed, returning pages offset from the
start of the disk rather than the start of the file. (ie, "cp" of
a 1-block file would get you a copy of the boot sector, not the
data in the file.) The solution isn't ideal, but gives a functioning
filesystem.
Cached vnode lookup was also broken, resulting in vnode haemorrhage.
A lookup on the same file twice would give you two vnodes, and the
resulting cached pages.
Just recently, mmap() was broken due to a lack of a call to
vnode_create_vobject() in ntfs_open().
Discussed with: phk@
60. The postinc store tests currently fail (value mismatch). Hence
the score as of this commit is 48 out of 60. Either the kernel or
the tests need to be fixed.
manpages. They are not very related, so separating them makes it
easier to add meaningful cross-references and extend some of the
descriptions.
- Move the part of math(3) that discusses IEEE 754 to the ieee(3)
manpage.
null-modem tty device emulate the speed settings faithfully.
The speed is emulated independently for the two directions, using
the slower of the local sides ispeed and the remote sides ospeed.
The emulated speed takes settings of bits/char, parity and stopbit
into account.
Inspired by: The BSD-DK Editor Celebrity Deathmatch Contest
and tabs. This is still not correct for command line variable values
ending in a backslash because this would require a larger effort.
Document this limitation in the BUGS section of the man page. The
quoting is mostly compatible with that of gmake and smake.
Tested by: Max Okumoto and Joerg Sonnenberger from DragonFly BSD
Reviewed by: ru (man page, partly)
suggestions which result in the last revision[*]:
- style(9) and sysexits(3) suggests that we use EX_*
as exit values, instead of some other values like
those returned from a system call as errno.
Additionally, follow Ruslan's suggestion about style(9) and
other style improvements:
- Since open(2) says that it returns -1 on errors,
explicitly determine whether it is returning -1
rather than whether the return value is less than
zero.
- Only set rval when there is no previous error.
This distinguishes the first error that occours.
- Use exit() in favor of return in main(), this is
suggested in old style(9), while the evolve has
fade the suggestion.
- Add some NOTREACHED comments.
- Add blank line after first { because no local variables
in usage()
Thanks to Ruslan for his tireless explaining of the code standards
and knowledge of the history of style(9).
[*] Pointy hat to: me
Submitted by: ru (with some minor changes)
Discussed with: ru, ssouhlal
i386_{get,set}_ioperm() and make those APIs visible in the kernel namespace;
o use i386_{get,set}_ldt() and i386_{get,set}_ioperm() instead of sysarch()
in the linuxlator, which allows to kill another two stackgaps.
MFC after: 2 weeks
the interface when going to toggle VLAN support for
internal reasons. If the IFCAP_VLAN_HWTAGGING bit is
cleared, we should rely on the (re)init routine to turn
VLAN support off and never touch the relevant hardware bits.
This applies to other capability bits, too. The user
obviously has a reason for clearing a capability bit,
e.g., if his particular NIC is buggy and hangs if a
certain hardware capability is turned on even for a
fraction of a second.
The flag adapter->em_insert_vlan_header still is set or
reset irrespective of the IFCAP_VLAN_HWTAGGING setting,
as before, in order to handle the case when a user sets
promiscuous mode on an interface first and later turns
its IFCAP_VLAN_HWTAGGING bit on.
This change might look orthogonal to rev#1.85, but in fact
it is not. It introduces bugfixes that hopefully will make
implementing the general scheme mentioned in the commit
message of rev#1.85 easier.
configuration: it appears to work properly in the non-promiscuous case, but
we've not yet implemented a more general solution that maintains full
functionality with promiscuous mode enabled. While my hope is that we can
get one implemented soon, this will improve functionality substantially in
the mean time.
MFC after: 3 days
