if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.
This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.
Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)
is returned from the card to the driver. Add a counter that shows
how many times this allocation has failed. Note, that we could even
further delay the allocation of the mbuf until we know, that we need it
(there are no receive errors and the connection is open). This will be done
in a later commit.
Print the new statistics field in atmconfig.
and to make sure that we catch oversized arguments rather than silently
truncate them. I dont know if sscanf will reject an integer if it will
not fit in the short return variable or not, but this way it should be
detected.
a generalized notification mechanism for subsystems wishing to report
events.
Revieded by: njl
# The kernel side seems like it might be causing panics for me, but should
# be forthcoming shortly.
(aka RFC2292bis). Though I believe this commit doesn't break
backward compatibility againt existing binaries, it breaks
backward compatibility of API.
Now, the applications which use Advanced Sockets API such as
telnet, ping6, mld6query and traceroute6 use RFC3542 API.
Obtained from: KAME
o WARNS should be WARNS?= (broke in rev 1.21).
o Includes should be sorted.
o Move "mntopt.h" out of the standard includes section.
o Rewrite usage() to match the manual page and make it < 80 characters.
o Remove extra .El call on line 187. It is unused and causes mdoc(7) warnings.
Discussed with: bde
original intention of the less restrictive permissions was to allow
users to move or delete recovered files that they own. However, it
is better to not create world-writable directories by default; the
administrator can always pre-create lost+found if different permissions
are desired.
Reviewed by: mckusick
the stack to the heap to work around a problem on ia64. Now, roughly
16 months and two compiler updates later, it isn't an issue anymore
in the sense that putting a 1M buffer on the stack just works and we
don't actually need to work around anything anymore.
However, since there's no advantage or need to put the buffer on the
stack (again), this change merely removes the XXX comment describing
that there's an explicit reason for the heap allocation. Hence, this
change is a functional no-op.
PR: ia64/38677
filesystem that is checked in background. Create the snapshot in this
directory rather than in the root. There are two benefits:
1) For terabyte-sized filesystems, the snapshot may require many
minutes to build. Although the filesystem will not be suspended
during most of the snapshot build, the snapshot file itself is
locked during the entire snapshot build period. Thus, if it is
accessed during the period that it is being built, the process
trying to access it will block holding its containing directory
locked. If the snapshot is in the root, the root will lock and
the system will come to a halt until the snapshot finishes. By
putting the snapshot in a subdirectory, it is out of the likely
path of any process traversing through the root and hence much
less likely to cause a lock race to the root.
2) The dump program is usually run by a non-root user running with
operator group privilege. Such a user is typically not permitted
to create files in the root of a filesystem. By having a directory
in group operator with group write access available, such a user
will be able to create a snapshot there. Having the dump program
create its snapshot in a subdirectory below the root will benefit
from point (1) as well.
Sponsored by: DARPA & NAI Labs.
