This allows me to accurately test this scenario, and for others to rely
on the behavior, instead of relying on knowledge obtained via code
inspection.
Wording borrowed from free(3).
MFC after: 1 week
Requested by: ken (D9928)
Reviewed by: imp
Sponsored by: Dell EMC Isilon
Differential Revision: D9969
- spelling: "mis-named" should be "misnamed".
- delete spaces interspersed in literal representation of
`struct cam_device` as hard-tabs separate the types and fields.
- Add commas after `e.g.`.
Reported by: igor
MFC after: 1 week
Sponsored by: Dell EMC Isilon
This is the correct markup macro, as opposed to .Va (variable names)
While here, annotate several bare references to `NULL` with .Dv.
MFC after: 1 week
Sponsored by: Dell EMC Isilon
The reasoning behind this, is that if we are consistent in our
documentation about the uint*_t stuff, people will be less tempted to
write new code that uses the non-standard types.
I am not going to bump the man page dates, as these changes can be
considered style nits. The meaning of the man pages is unaffected.
MFC after: 1 month
Remove or re-work support for the several features from the past:
- remove incomplete support for trimming slice/partition names
- remove mapping from old device names "sd" and "st"
- remove whitespace trimming
- remove unconditional skipping of leading 'r' in a device name
- skip leading 'n' or 'e' only if the following device name matches
a list of known devices that support no-rewind and eject-on-close
features; currently this is only sa(4)
- reflect the above changes in comments in code and in cam(3)
- remove a note cautioning against use of cam_get_device and
cam_open_device in cam(3)
Reviewed by: mjacob
Although groff_mdoc(7) gives another impression, this is the ordering
most widely used and also required by mdocml/mandoc.
Reviewed by: ru
Approved by: philip, ed (mentors)
- Sort xrefs
- FreeBSD.ORG -> FreeBSD.org
- Be consistent with section names as outlines in mdoc(7)
- Other misc mdoc cleanup.
PR: doc/13144
Submitted by: Alexy M. Zelkin <phantom@cris.net>
most of the open/close routines, and the buffer/cdb parsing routines
derived from the old scsi(3) library.
The cam_cdbparse(3) man page borrows from the old scsi(3) man page, so the
copyright and history section reflect that.
The many scsi_* functions and other functions that are pulled in from the
kernel aren't documented yet, but will be eventually.
