Bug 234027 - [ioat] ioat man page belongs in section 9
Summary: [ioat] ioat man page belongs in section 9
Status: Closed Works As Intended
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-doc (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-14 23:59 UTC by Alan Somers
Modified: 2023-10-06 12:14 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Somers freebsd_committer freebsd_triage 2018-12-14 23:59:30 UTC 
The ioat(4) driver can only be accessed from kernelspace, so it should probably be moved to section 9.  Also, the cross-referenced program ioatcontrol(8) is a dead link.  That program doesn't get installed and neither does its man page.  ioat(4) should probably just refer to its source location instead: tools/tools/dev/ioat/ioatcontrol.
Comment 1 Conrad Meyer freebsd_committer freebsd_triage 2018-12-15 00:40:30 UTC 
I'm not sure about the section 9 claim.  Is there precedent one way or the other?

As far as ioatcontrol(8): yeah, I agree that should be fixed — there's no reason that program should live outside of tools/ or tests/.
Comment 2 Conrad Meyer freebsd_committer freebsd_triage 2018-12-15 00:41:31 UTC 
Btw, it looks like xdma(4) (undocumented entirely, of course) is the start of a generic DMA engine interface ioat(4) might implement.  Unfortunately, last time I looked the interface wasn't general enough for ioat.
Comment 3 Alan Somers freebsd_committer freebsd_triage 2018-12-15 01:40:09 UTC 
I guess there is precedent for leaving it in section 4.  ciss(4) and cpufreq(4) both have similar API documentation in section 4.