#
315606 |
|
20-Mar-2017 |
ngie |
MFC r315132,r315133,r315186:
r315132:
Use .Dv when referencing NULL
This is the correct markup macro, as opposed to .Va (variable names)
While here, annotate several bare references to `NULL` with .Dv.
r315133:
lib/libcam/cam.3: fix manpage warnings
- 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.`.
r315186:
lib/libcam/cam.3: note that cam_freeccb(3) with ccb == NULL is a no-op
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).
Requested by: ken (D9928)
|
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
231564 |
|
12-Feb-2012 |
ed |
Globally replace u_int*_t from (non-contributed) man pages.
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
|
#
213682 |
|
11-Oct-2010 |
avg |
cam_get_device, cam_open_device: make behavior simpler and more deterministic
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
|
#
210933 |
|
06-Aug-2010 |
joel |
Fix typos and spelling mistakes.
|
#
206622 |
|
14-Apr-2010 |
uqs |
mdoc: order prologue macros consistently by Dd/Dt/Os
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)
|
#
141846 |
|
13-Feb-2005 |
ru |
Expand *n't contractions.
|
#
131539 |
|
03-Jul-2004 |
ru |
Eliminate double whitespace.
|
#
131504 |
|
02-Jul-2004 |
ru |
Mechanically kill hard sentence breaks.
|
#
84306 |
|
01-Oct-2001 |
ru |
mdoc(7) police: Use the new .In macro for #include statements.
|
#
79754 |
|
15-Jul-2001 |
dd |
Remove whitespace at EOL.
|
#
79531 |
|
10-Jul-2001 |
ru |
mdoc(7) police: removed HISTORY info from the .Os call.
|
#
73186 |
|
27-Feb-2001 |
obrien |
Remove the `r' devices.
|
#
70015 |
|
14-Dec-2000 |
ru |
mdoc(7) police: removed history info from the .Os FreeBSD call.
|
#
59503 |
|
22-Apr-2000 |
phantom |
Introduce .Lb macro to libcam manpages.
|
#
50476 |
|
27-Aug-1999 |
peter |
$Id$ -> $FreeBSD$
|
#
49984 |
|
17-Aug-1999 |
ken |
Take out a reference to ccb(4). I never got around to writing it.
Reported by: "Alexey M. Zelkin" <phantom@cris.net>
|
#
49828 |
|
15-Aug-1999 |
mpp |
Various man page cleanup:
- 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>
|
#
44489 |
|
05-Mar-1999 |
bde |
Fixed missing header in synopsis (<camlib.h> includes half the universe but not <stdio.h>).
|
#
40337 |
|
14-Oct-1998 |
ken |
Add man pages for many of the functions in the CAM library. This covers 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.
|