interfaces we encounter. In Linux, all addresses are returned for
which gifconf handlers are installed. This boils down to AF_DECnet
and AF_INET. We care mostly about AF_INET for now. Adding additional
families is simple enough.
Returning the addresses is important for RPC clients to function
properly. Andrew found in some reference code that the logic that
handles the retransmission looks for an interface that's up and has
an AF_INET address. This obviously failed as we didn't return any
addresses at all.
Note also that with this change we don't return interfaces that don't
have AF_INET addresses, whereas before we returned any interface
present in the system. This is in line with what Linux does (modulo
interfaces with only AF_DECnet addresses of course :-)
Reported by: "Andrew Atrens" <atrens@nortelnetworks.com>
MFC after: 1 week
vinumioctl: Fix a double fault caused by calling setjmp() without
holding the config lock. The call was in fact
superfluous.
Dump analysis by: Thomas Moestl <tmoestl@gmx.net>
Forced commit requested by: obrien, kris
apply to this file. The correct message is:
throw_rude_remark: Make sure we're holding the config lock before
proceeding. There's no reason to assume that this
has ever happened, but the alternative might be a
double fault.
/usr/share/examples/pppd.
Remove the out-of-place pppd(8) configuration files in etc/ppp,
ppp.shells.sample and ppp.deny.
Make the appropriate changes to the build process, etc/Makefile and
etc/mtree/BSD.usr.mtree, so it all works.
/usr/share/examples/pppd.
Update pppd(8) documentation to reflect this, usr.sbin/pppd/pppd.8.
Remove the out-of-place pppd(8) configuration files in etc/ppp,
ppp.shells.sample and ppp.deny.
Make the appropriate changes to the build process, etc/Makefile and
etc/mtree/BSD.usr.mtree, so it all works.
The files from etc/ppp, ppp.shells.sample and ppp.deny, were moved
with a repo copy. Note it in the logs with a forced commit to these
two.
Submitted by: Maxim Konovalov <maxim@macomnet.ru> provided the new samples.
handlers to set flags only (with exception for sigquit(),
which still seems to call some non-reentrant functions on
its way to _exit(2).) That must eliminate the possibility
of catching SIGSEGV from following non-reentrant paths from
signal handlers.
PR: bin/32740 bin/33846
Submitted by: Maxim Konovalov <maxim@macomnet.ru>
Obtained from: OpenBSD
less robust to possible errors of the user/admin while adduser(8)
had been intended to minimize their possibility.
An alternative way of introducing strange symbols into usernames
to be committed really soon.
This change was submitted to the freebsd-audit mailing list for review
but received no feedback. Hindsight-enabled reviews are welcome.
PR: conf/31358
Submitted: Thomas Quinot <thomas@cuivre.fr.eu.org>
# This card has the same PCMCIA and OEM id as ELSA XI300 wireless card, which
# appears to be listed elsewhere in this file.
Submitted by: Abe Toshiaki-san <ans@sun-tec.co.jp>
MFC After: 5 days
uhub.c: revision 1.37
usb.4: revision 1.30
usb.c: revision 1.38
usb.h: revision 1.40
usb_port.h: revision 1.21
usb_subr.c: revision 1.65
usbdi.h: revision 1.40
Split the attach/detach events up into device, driver and controller
attach and detach events.
The commit message from NetBSD was:
date: 2000/02/02 07:34:00; author: augustss; state: Exp;
Change the USB event mechanism to include more information
about devices and drivers. Partly from FreeBSD.
Also rework usbd to take these new event types into account.
for success, non-zero otherwise. The maestro and maestro3 drivers were
returning the format code, which was being interpreted as a failure code.
Fixed. No one seems to have noticed that the maestro driver was broken,
but I'll fix it anyways.
MFC after: 2 weeks
64-bit platforms. The unaligned access is caused by struct ifa_msghdr
not being a multiple of 8-bytes in size. If an interface has an odd
number of addresses, this causes the next interface to generate an
unaligned access in the user-level app walking the interfaces (ifconfig).
Submitted by: Bernd Walter <ticso@cicely8.cicely.de>
(which allows one to redirect output to stdout); `-o /dev/stdout' is
recommended instead.
Submitted by: Joseph Mallett <jmallett@xMach.org>
MFC after: 2 weeks
