Such a guard is bound to be almost always false (obviously).
Reviewed by: emaste (older version)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49974
(cherry picked from commit 613d66b5e17d92e5304fdc9abe4c62ba015ebf31)
Support enabling debugging macros for userland and _STANDALONE builds,
in addition to the already existing kernel support. On runtime error,
panic() is used for kernel and _STANDALONE builds, and a simple
fprintf() + abort() combination for userland ones. These can be
overriden if needed by defining the QMD_PANIC() and/or QMD_ASSERT()
macros.
The expansion of queue debug macros can now be controlled more finely
thanks to the QUEUE_MACRO_DEBUG_ASSERTIONS and
QUEUE_MACRO_NO_DEBUG_ASSERTIONS macros. The first one serves to
forcibly enable debug code and the second to forcibly disable it. These
are meant to be used as compile options only, and should normally not be
defined in a source file. It is an error to have both of them defined.
If none of the two above-mentioned macros are defined, an automatic
determination is performed. When compiling kernel code,
QUEUE_MACRO_DEBUG_ASSERTIONS is defined if INVARIANTS has been defined
(as before). For userland and _STANDALONE builds, no debug code is ever
automatically inserted even if NDEBUG is not defined, as doing so would
inflate code size and users may want to have working assert() calls
without this overhead by default.
In the manual page, document check code control under DIAGNOSTICS.
While here, rework a bit the rest of the DIAGNOSTICS section.
Reviewed by: markj (older version)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49973
(cherry picked from commit 1c5fea9e8b563186b8f5773064458c4ecf2d7004)
Include it as <sys/kassert.h> has direct references defined in it (to
'__va_list' and '__printflike' at least).
This is a step to make <sys/kassert.h> usable without the need to
explicitly include other headers.
Reviewed by: imp, markj
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49972
(cherry picked from commit 0f2090ccfeb6e3e1a2290300b53baedfb057c2b5)
Reviewed by: markj
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49970
(cherry picked from commit a4df0830d74dba9d20c01d8c108bddeb1ecd62cd)
This is what POSIX mandates for option '-U' and arguably the behavior
that most users actually need in most cases. Before, '-U' would select
processes by their effective user IDs (which is the behavior mandated by
POSIX for option '-u').
Matching by real user IDs allows to list all processes belonging to the
passed users, including those temporarily having a different effective
user ID, which can happen if launched by a setuid executable or if using
some credentials-changing facility (such as seteuid() for root processes
or mac_do(4)/setcred(2)). Conversely, processes temporarily assuming
the identity of some of the passed users will not be listed anymore
(they do not "belong" to these users).
This change also makes '-U' consistent with '-G', the latter already
matching on real group IDs.
While here, remove the (non-compiled) code for tentative option '-R' as
its proposed behavior was the one established here for '-U'. Also, move
the compiled-out old code for '-U' under '-u' for reference, as this is
what the latter should do according to POSIX, even if it seems unlikely
we will want to change the behavior of '-u'.
Reviewed by: manpages (ziaee)
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49622 (code)
Differential Revision: https://reviews.freebsd.org/D49623 (manual page)
(cherry picked from commit 995b690d1398044dc9d85a6d86ec550cda30b2ac)
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49621
(cherry picked from commit 2d7f70975bd8146f36b35477a8a1be490a0afc95)
This puts our ps(1) in conformance with POSIX.
While here, replace ad-hoc initialization of 'uidlist' with a call to
expand_list().
***
Review of the ps(1) implementations in other BSDs, illumos, and Linux's
procps shows they already behave as prescribed by POSIX.
Previously, we would match processes with their effective user ID but
using our real user ID. While the real user ID is meant as the real
identity of a process, and is used, e.g., to perform accounting or be
permitted to send signals to specific targets, selecting processes to
display is arguably more akin to a kind of (advisory) access control.
ps(1) is not installed setuid, so normally the real and effective user
IDs of ps processes are the same. This may however not be the case when
ps(1) is launched by another setuid executable, and the launching
process may then logically expect that ps(1) lists the processes
corresponding to its effective UID.
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49619 (code)
Differential Revision: https://reviews.freebsd.org/D49620 (manual page)
(cherry picked from commit 1aabbb25c9f9c4372fd68621f8cabdc10b665527)
When combined with other options affecting the selection of processes,
except for '-X' and '-x', option '-a' would have no effect (and '-A'
would reduce to just '-x'). This was in contradiction with the rule
applying to all other selection options stating that one process is
listed as soon as any of these options has been specified and selects
it, which is both mandated by POSIX and arguably a natural expectation.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49617 (code)
Differential Revision: https://reviews.freebsd.org/D49618 (manual page)
(cherry picked from commit 93a94ce731a89b5643021b486da599e7963da232)
The ps(1) display's list of columns is now first built without taking
into account the '-O' options. In a second step, all columns passed via
'-O' are finally inserted after the built-so-far display's first PID
column (if it exists, else at start), in their order of appearance as
arguments to the '-O' options.
This new two-step procedure suppresses the following undesirable
behaviors:
- '-O' used to insert the columns of the default display even if the
user also passed other options to request specific columns.
- Each occurence of '-O' beyond the first would just insert the passed
keywords after those requested by the previous options, as if by '-o',
inconsistently with the behavior for the first occurence.
These behaviors had more annoying consequences:
- Where the columns of some '-O' occurence appear in the display used to
depend on the actual position of '-O' with respect to other options,
despite the natural expectation that they should go near a single PID
column considered as an anchor regardless of other options adding
columns.
- Columns specified with multiple '-O' options would not be grouped
together.
- It used to be impossible to specify custom headers but for the last
column for columns that are next to each other (i.e., specified by
a single '-O' occurence).
which are now all lifted.
With these changes, '-O' can still be used alone to amend the default
display, but can now be used also in conjunction with any specific
display, and in particular "canned" ones invoked by '-j', '-l', '-u' or
'-v'.
******
This part discusses other ps(1) implementations' behaviors and compares
them to the one established by this change.
NetBSD seems to be the only other BSD having refined the meaning of
ps(1)'s '-O' option. While the behavior there is similar to the new one
here on the surface, it differs on the following points:
1. If no options requesting a specific display are present before the
first '-O' option, the appearance of '-O' triggers the insertion of
the default display, regardless of whether such specific display
options appear *after* it.
2. If options requesting a specific display appear before the first '-O'
and none specify a PID column, columns listed in the first '-O' are
appended to them (as '-o' would do), but columns passed by further
'-O' options are then inserted next to the columns of the first '-O'
options.
Behavior of point 1 seems to have only one advantage: To allow to
customize the default display by first using '-O' and then other options
appending to it, but as the default display finishes with the COMMAND
column, it is unlikely that one wants to use '-o' or other specific
display options after '-O' (NetBSD's ps(1) does not suppress duplicate
columns). A much simpler and easy-to-understand way to reach that
effect in FreeBSD, if it really proves useful, would be to introduce
a new explicit option that inserts the default display.
The column-appending behavior of the first '-O' option in point 2 can be
also achieved by using '-o' instead. As '-O' is used to insert columns
after the PID one, which is located near the left in the default and all
"canned" displays, we found it more consistent and practical to push its
columns completely to the left on the absence of a PID column. The
effect of multiple '-O' options in NetBSD when no PID column has been
requested beforehand is also cumbersome and inconsistent with the
documentation (it is likely a bug).
Both NetBSD-specific behaviors exposed above also have the disadvantage
that the position of '-O' options with respect to other ones is
meaningful in ways that are not obvious and that are arguably not
desirable as '-O' is meant to append columns after an anchor (the PID
column).
Linux's procps-ng's ps(1) is very limited in its handling of '-O', and
more generally when mixing options tweaking the display. '-O' causes
insertion of the default display (like NetBSD does). If '-o' options
are specified, '-O' must come before them. '-O' is not usable with
canned display options. Additionally, only one '-O' option may appear
on the command line, limiting header customization.
The only case in which these implementations and ours behave in the same
way with respect to '-O' is if only a single '-O' option and no other
options changing the display are specified.
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49615 (code)
Differential Revision: https://reviews.freebsd.org/D49616 (manual page)
(cherry picked from commit 5dad61d9b949bb859450266c6accebc106f50fcc)
*_SPLIT_AFTER() allows to split an existing queue in two. It is the
missing block that enables arbitrary splitting and recombinations of
lists/queues together with *_CONCAT() and *_SWAP().
Add *_ASSERT_NONEMPTY(), used by *_SPLIT_AFTER().
Reviewed by: markj
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49608 (stailq)
Differential Revision: https://reviews.freebsd.org/D49969 (rest)
(cherry picked from commit c02880233949b01fcfb2067962596f5c05553471)
Now that removal of non-explicitly-requested duplicate columns work with
a O(n) algorithm, remove the ad-hoc optimization of crushing the canned
displays' formats after first use and constify their format strings.
No functional change intended.
This change could also be useful if/when allowing, e.g., to double
letters of canned displays to indicate their columns should not be
subject to automatic removal of duplicates (e.g., 'ps -ll').
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49614
(cherry picked from commit fd6b81712eb9a77bbe484954d18fe1fc4a27116b)
Before this change, when stacking up more columns in the display through
command-line options, if user requested to add some "canned" display
(through options '-j', '-l', '-u' or '-v'), columns in it that were
"duplicates" of already requested ones (meaning that they share the same
keyword, regardless of whether their headers have been customized) were
in the end omitted.
However, this mechanism did not work the other way around, i.e.,
requesting some canned display(s) first and then adding some columns
that are duplicates (through '-o' or '-O') would not remove them from
the canned display. Additionally, it did not take into account keyword
aliases (which also lead to displaying the same information).
This whole mechanism of removing columns from requested canned displays
when there are duplicates is useful in a number of scenarios:
1. When one wants the columns of a canned display, but with some of them
in a different order and at the edges of the bulk. This needs the
change here to move columns after the bulk (previously, only moving
them before the bulk would work).
2. To combine multiple canned displays to get more information without
repeating common columns. This part has been working before and
this behavior is unchanged.
3. In combination with requesting a canned display and additional
columns after it, ensure that a single COMMAND column appears at the
end of the display (to benefit from the fact that a last COMMAND
column can extend further to the right).
Point 2 above implies that, when multiple canned displays are requested,
we should keep the leftmost column with same keyword. However, columns
requested explicitly by '-o' have priority (as the natural extension of
point 1's behavior before this change), and in this case all matching
columns in canned displays must be suppressed.
To this end, when adding requested options to the display's list, we
stop trying to find an earlier matching column (which is incidentally
a O(n²) algorithm). Instead, we do a first pass over all requested
options once they have all been added to the display's list (in
scan_vars()). For each keyword, we note if it was requested at least
once explicitly (through '-o' or '-O'), in addition to setting
'needuser' and 'needcomm' (as before). Then, a second pass decides
whether to keep each column. A column is removed if it should not be
kept absolutely (i.e., it wasn't specified via '-o' or '-O') and there
is either a matching column that must be kept (determined during the
first pass), or we have seen one already (earlier canned displays take
precedence).
Matching columns are in fact not only those that have same keywords, but
also those that have keywords determined to be aliases to each other.
Some previous commits ensured that this determination is O(1) and in
practice just a few assembly instructions.
find_varentry() has been kept although its last caller has been removed
as next commit will reintroduce a call to it.
MFC after: 3 days
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49612
Differential Revision: https://reviews.freebsd.org/D49613 (manual page)
(cherry picked from commit cd768a840644ad55029ce9c3d41fc52b5045e0cc)
With this change, an alias keyword is resolved once and for all by
merging specifications of the keyword (or chain of keywords) it points
to. This merge in particular determines the final attributes of the
alias keyword, as well as the final keyword it points to, which uniquely
determines which information is printed (all non-alias keywords are
assumed to display different data).
Also, the alias resolving code has been moved into the resolve_alias()
function and helpers (e.g., merge_alias()). Aliases are still resolved
lazily as needed by default. The new top-level resolve_aliases()
function is used to resolve them at once at program startup if ps(1) has
been compiled with PS_CHECK_KEYWORDS defined. Else, it can also be
called directly from a debugger.
This is in preparation for removing columns that actually display the
same information in a subsequent commit, as this requires being able to
(quickly) determine if they are aliases to each other.
***
The merge process is now explicit and more flexible. Previously, all
fields of the resolved keyword were unconditionally used for the alias
(the pointer to an alias keyword structure was replaced by one to the
aliased keyword's one). Now, field 'final_kw' on the alias keyword will
store a pointer to the aliased keyword structure (and not only its name,
as a subsequent commit will need the structure address). Fields
'header', 'field' and 'flag' are taken from the aliased keyword if they
have default values (NULL or 0), else the alias' values prevail. This
allows an alias to override one or more of these fields. All fields
after 'oproc', because they describe the information to display
consistently with each other, are always taken from the aliased keyword.
merge_alias() checks that the values of these fields in the alias
keyword structure are unspecified (NULL, or some neutral value like
0 and UNSPEC).
While here, parsefmt() was reworked to avoid any direct recursion and
the break-up/recombination steps that were used when processing aliases.
The latter was due to the mutual recursion with findvar() and its
odd-for-that-purpose signature. findvar() has been removed in the
process. Simplification of parsefmt() also allows to be more precise
with the errors reported (in particular, the case of an empty keyword
with a specific header would just be reported as a "keyword not found"
message).
While here, introduce the check_keywords() function, performing sanity
checks on the declared keywords, currently only validating that they are
declared in alphabetical order. As for resolve_aliases(), this function
is called at startup on PS_CHECK_KEYWORDS, else it is available to be
called from a debugger.
Ideally, alias resolution should be done at compile time. In practice,
it seems doing so at runtime was never a problem (there are only a few
aliases compared to all available keywords, and there's currently at
most one level of aliasing). With the changes here, it seems very
unlikely to become one even if many more keywords, aliases or aliasing
levels are added.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 193e68d5174ffde70acc427f9d830797df9a13cb)
This is in preparation for a change in how aliases are resolved, itself
in preparation for being able to quickly identify columns displaying the
same information (same final keyword).
Add the new UNSPEC ("unspecified") type, as the keywords' type field is
only used by the kvar() and rvar() output routines, and has no meaning
for alias keywords. In particular, this will allow to check that no
specific type is associated to any alias. An immediate benefit is that
now most keywords have UNSPEC as their "type", which now makes
kvar()/rvar() explicitly fail (instead of trying to print a character,
as the previous CHAR type was requesting). A developer introducing new
keywords via copy-paste will thus be reminded that it also needs to set
'type' meaningfully if using kvar()/rvar() as the output routine.
Rename field 'alias' of keywords ('VAR' type) into 'aliased'. Move it
just after the keyword's name, as it makes it easier to spot aliases in
the list. Make it a union, as a subsequent commit will... alias it with
a pointer to another 'VAR' structure. Turn aliases' header string (""
for all aliases) into NULL. It is currently not used, but will be when
introducing the new "merge" procedure for aliases (where it will mean:
Use the header of the aliased keyword).
While here, rename vars[] into the more descriptive keywords[].
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 090f0e5820efc7f9459d1e4eb1be17fb98848df5)
Building on the previous commit that moved the 'width' field from VAR
(structure representing the meaning of a keyword) to VARENT (structure
representing an actual column in a display), it is now possible to
declare the field 'var' of VARENT as a constant reference.
At this point, it could be possible to constify the var[] array
containing all the recognized keywords. However, we do not do it as
a subsequent commit will change the way alias keywords are resolved,
causing their fields to be modified to reflect the final values to use
after alias resolution.
In parsefmt(), forget about allocating a new VAR for the selected
keyword to be pointed by the corresponding column (VARENT), and instead
just keep a pointer to that structure in var[].
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49611
(cherry picked from commit 1dbb1cca9b8b7874f22c06f5340686361c76da47)
Some column's width depends not only on the information displayed but
also on the its header, which may have been customized. Consequently,
that width is a property of the actual column and should not be attached
to the keyword specifying which information to print.
This change fixes a bug where multiple columns displaying the same
information (same keyword) but with different headers would have the
same width, although they should not if they have long enough headers
that have different lengths (the width computed from the largest header
would be applied to all the corresponding keyword's columns).
Remove sizevars(), as the 'width' field is now initialized directly in
parsefmt(), which creates the VARENT structures.
While here, remove var[]'s sentinel line, and consequently adjust the
upper limit in showkey()'s loop and findvar()'s binary search.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49610
(cherry picked from commit 490f251bf90dbfda8043e2d1f4a71dd3a91a8628)
The only information that find_varentry() needs and uses is
a keyword/var name. The rest of the fields in the passed VAR are
unused.
Changing its signature will ease introducing new calls to
find_varentry() in subsequent commits, as there no VAR object will exist
to be passed but just a name.
Reviewed by: kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49609
(cherry picked from commit c1e5a7fdad631458768fc45a82b4d43bade8d0c8)
This is in preparation for changing the behavior of the '-O' option.
While here, reformat the definition of 'struct varent', fix formatting
of that of 'struct var' and expand slightly their herald comments.
More reformatting/commenting in 'ps.h'.
No functional change intended.
Reviewed by: kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49607
(cherry picked from commit 07a7557addc03acd28aaae55b90419c4ef9d9ad1)
Now that it is officially documented in the manual page.
Reviewed by: kib
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49606
(cherry picked from commit 8a3e58ed618109e7af16c54affb1d5f98e5feb27)
No functional change (intended).
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 0d320eb5edc37f6c1bfa5eabc0309350b87c08ad)
The preamble has been revamped to give a thorough overview of the
different aspects of the ps(1) command in the following separate
paragraphs:
1. What it outputs.
2. Which processes are listed.
3. Which information is displayed by process.
4. How lines are sorted.
5. Considerations about the (mostly broken) output width.
6. Backwards compatibility features.
Fix or expand the description of several options and some keywords to
match their actual behavior.
Expand the STANDARDS section, noting the options conforming to POSIX and
those that do not (but may be changed to), as well as current diverging
behaviors.
Expand the BUGS section with a thorough description of other known
problems.
While here, document the POSIX-specified '-A' option. We have been
supporting it since 2004 (commit "Support more POSIX/SUSv3 options:",
a4c8a745a8, r127499) and it has been standard for longer. It
seems now highly unlikely we will ever want to use it for any other
purpose, so just stop trying to hide it.
While here, re-order flags according to mdoc(7)'s prescription. Given
the current state, this also requires less changes than, e.g., putting
all uppercase flags first.
While here, move the detailed specifications of keywords from the
DESCRIPTION to the KEYWORDS section.
While here, fix the formatting of some references to keywords.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49605
(cherry picked from commit ddf144a04b53d8599bdd00747e1b6d77e695c292)
On MFC, the original description for '-f' was kept, as swapping out has
not been removed from stable/14, and was slightly tweaked to be clearer.
Reviewed by: des
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D41422
(cherry picked from commit e17a2944a6e08478b9c073ba62c46f6714af16a2)
I just noticed a slight issue with the '-D' option. Basically,
I accidentally typed something along the lines of:
ps -Dboth-p303
I.E. missing out the "space". Instead of giving an error, it behaved as
if I'd just typed "ps".
Looking at bin/ps/ps.c, where the -D option is parsed, it doesn't
error-out if there is no valid match.
This commit fixes the bug.
(cherry picked from commit 3f0b80bc1537c257f3bd68592832ec8cb65e1c58)
The -p option does not imply -x, it is merely a different mode that ps
uses. Remove that statement from the -p option, effectively rolling back
d6ae056e9dc96c2db45982ac358ba9ed716a9202.
pstef@ introduced the -D option in 5c0a1c15ff
which also turns ps into a similar mode. List the -D option along with
the others in the first sentence of the second paragraph of the
DESCRIPTION section for completeness and correctness sake.
Pointed out by: pstef@
Differential Revision: https://reviews.freebsd.org/D42552
(cherry picked from commit ba44650a0b1e3b0f52554380937a3ffc16d396f3)
Add a missing space before R-HIWA to align the table header with
the table contents.
Reviewed by: rrs, cc
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D49941
(cherry picked from commit 4294f7946e4cd8face2bfa16cedc5c0bf0d6c81e)
When the file system does not support symbolic links (like in the case
of MSDOS), symlink() returns -1 and sets errno to EOPNOTSUPP.
Document this behavior.
Reviewed by: glebius, markj
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D49803
(cherry picked from commit dd9e59beebbb346f329dfd1de26a84da8afdcb1d)
Remove the macros COPY_STAT and COPY_STAT_T, since they do not improve
the readability of the code. No functional change intended.
Thanks to glebius@ for suggesting the change.
Reviewed by: glebius, rrs
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D49670
(cherry picked from commit 46fc12741e70f2d1f0510a0dacd2f9dd3aa116c0)
Changes since 2.8.0:
Bug Fixes:
* Fix LLQ normal width misconfiguration
* Check for errors when detaching children first, not last
Minor Changes:
* Remove \n from sysctl description
Approved by: cperciva (mentor)
Sponsored by: Amazon, Inc.
Differential Revision: https://reviews.freebsd.org/D50041
(cherry picked from commit 59b30c1a864ee8a22c2e9912301cb88674f714c9)
Patch 0a33c047a443 introduced new values to
hw.ena.force_large_llq_header. The default value of 2 means no
preference, while 0 and 1 act as the previous false and true
respectively, which allowed forcefully setting regular or large LLQ.
There are 2 ways to force the driver to select regular LLQ:
1. Setting hw.ena.force_large_llq_header = 0 via sysctl.
2. Turning on ena express, which makes the recommendation by the FW to
be regular LLQ.
When the device supports large LLQ but the driver is forced to
regular LLQ, llq_config->llq_ring_entry_size_value is never initialized
and since it is a variable allocated on the stack, it stays garbage.
Since this variable is involved in calculating max_entries_in_tx_burst,
it could cause the maximum burst size to be zero. This causes the driver
to ignore the real maximum burst size of the device, leading to driver
resets in devices that have a maximum burst size (Nitro v4 and on. see
[1] for more information).
In case the garbage value is 0, the calculation of
max_entries_in_tx_burst divides by 0 and causes kernel panic.
The patch modifies the logic to take into account all use-cases and
ensure that the relevant fields are properly initialized.
[1]: https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html
Fixes: 0a33c047a443 ("ena: Support LLQ entry size recommendation from device")
Approved by: cperciva (mentor)
Sponsored by: Amazon, Inc.
Differential Revision: https://reviews.freebsd.org/D50040
(cherry picked from commit 56c45700f2ae15755358f2da8266247613c564df)
The man page ascii(7) first appears in the first edition manual.
Reviewed by: imp, Alexander Ziaee
Obtained from: OpenBSD
Differential Revision: https://reviews.freebsd.org/D48224
(cherry picked from commit 6145586a6c74e99969d74384066ecaf6580a8015)
Build and install the shrunk version of the time zone database required
by libc++ 19 std::chrono::current_zone (etc). While here, also install
the tzdata 'version' file to align more closely with other vendors.
PR: 282377
Reviewed by: dim, emaste, imp
Differential Revision: https://reviews.freebsd.org/D49577
(cherry picked from commit 91506dba7f2eb147eeb55ec30640bc11755a1e8e)
Broadcom's MPT-Fusion version 4 driver only works on 64-bit systems, and
has only been tested in amd64 and aarch64, so move it's building to just
those. I didn't notice this in the review and neglected to test those
cases (since I knew it didn't work there, so was a blind spot).
Pointy-hat: imp
Fixes: 9cdd40759617
Sponsored-by: Netflix
Sponsored by: Netflix
(cherry picked from commit 2f721943bf20e53b0ba7b5032a2900d0beb67413)
Registered the mpi3mr driver source files in sys/conf/files, enabling it
to be compiled into the base kernel image. This matches the approach
used for existing Broadcom drivers such as mrsas, mps, and mpr.
Add mpi3mr to sys/conf/NOTES.
With this change, the mpi3mr driver will be built as part of the base
kernel, allowing automatic loading during boot when supported hardware
is detected.
Below changes are suggested by chs@:
- Corrected the file name typo mistake in /sys/conf/files from
mpi3mr_app.c.c to mpi3mr_app.c
- Added mpi3mr driver entries in "sys/amd64/conf/GENERIC" and
"sys/i386/conf/GENERIC"
Reviewed by: ssaxena, chs, imp
Differential Revision: https://reviews.freebsd.org/D49754
(cherry picked from commit 9cdd40759617b15fdd6939d33f67aa2c9d2a6b1e)
qThis change was made after feedback from upstream, aiming to align with
the style guide for consistent log formatting. No functional changes
were made to the driver, only the formatting of the log messages.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49799
(cherry picked from commit 4494ea5406f79a6cb2d3631a723eb286ca96a9b9)
The driver version has been updated to 8.14.0.2.0 to reflect the
latest release. This is a version-only update with no functional
code changes.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49753
(cherry picked from commit f4d51d3e1a90dabbed26aacf1b58e20e23a19342)
All driver source files have been updated to reflect the year 2025.
This change is cosmetic and does not affect functionality.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49752
(cherry picked from commit 69be9a247b845b35146fed4575dacb565c9c18ba)
The driver now processes LOG Data events in the interrupt top
half instead of the bottom half. This allows LOG events to be
handled immediately upon receipt, reducing latency and enabling
early notification to the Library or applications.
This change ensures LOG event handling occurs closer to the
firmware's generation point, improving alignment with event-driven
diagnostic and monitoring mechanisms.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49751
(cherry picked from commit df8a74fca036a0ba8026f3ae3da830dffb922faa)
This patch ensures the driver sets the Diag Save bit for all
diagnostic fault conditions before issuing a Diagnostic Fault Reset.
The firmware now incorporates logic to manage snapdump saving
and requires the driver to always set the Diag Save bit to enable
this feature. This change supports improved diagnostic data
collection and fault handling.
Reviewed by: ssaxena, imp
Differential Revision: https://reviews.freebsd.org/D49750
(cherry picked from commit b854677d970a11e87929fa95d0e4067f911faa62)
The driver previously blocked I/Os only for OS-initiated task
management commands. This patch extends the behavior to also
block I/Os during application-initiated task management
operations (excluding Task Abort).
Before submitting such commands to the firmware, I/O
submissions are paused for the respective device. Once the
command completes, I/O operations are resumed.
This ensures safe and consistent task management handling.
[[ Note: Warner landed this with the pending suggestion
since this change is good enough for 14.3, but chs' suggestion
for better atomics needs to be implemented soon ]]
Discussed with: imp, chs
Differential Revision: https://reviews.freebsd.org/D49749
(cherry picked from commit 49445b54638f7b2d45942edd61c70fe0baa28f37)
