Page MenuHomeFreeBSD

newbus: Update docs on child_pnpinfo_str and child_location_str
AbandonedPublic

Authored by imp on Apr 16 2021, 4:35 AM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 20 2024, 8:06 PM
Unknown Object (File)
Mar 18 2024, 4:58 AM
Unknown Object (File)
Jan 1 2024, 3:52 AM
Unknown Object (File)
Dec 29 2023, 9:28 PM
Unknown Object (File)
Nov 2 2023, 3:20 AM
Unknown Object (File)
Sep 30 2023, 3:20 AM
Unknown Object (File)
Aug 28 2023, 10:46 AM
Unknown Object (File)
Aug 10 2023, 9:52 PM
Subscribers
None

Details

Reviewers
jhb
Summary

Only one driver in the tree with a non-trivial child_pnpinfo_str (acpi_iicbus)
returns EOVERFLOW. None do for location_str. Since it's not really an an
observed interface in the other 34 instances; and since nothing does anything
with this return value. Remove it from the API contract.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 38615
Build 35504: arc lint + arc unit

Event Timeline

imp requested review of this revision.Apr 16 2021, 4:35 AM
imp created this revision.

Sadly, there appears to be no man page for either of these functions.

imp retitled this revision from Update docs on child_pnpinfo_str and child_location_str to newbus: Update docs on child_pnpinfo_str and child_location_str.Apr 21 2021, 9:01 PM
In D29791#668246, @imp wrote:

Sadly, there appears to be no man page for either of these functions.

I might know which person added the functions in the first place. :)

My only thought about this change is that it no longer describes the return value at all, though perhaps you just want to remove the EOVERFLOW check. Should we also remove the check from the one driver as part of this? (And what do other drivers do, do they truncate? You were going to change it to write to an sbuf I thought at one point?)

In D29791#670956, @jhb wrote:
In D29791#668246, @imp wrote:

Sadly, there appears to be no man page for either of these functions.

I might know which person added the functions in the first place. :)

Yes. back in my wild, carefree youth I may have had occasion to add kernel interfaces w/o man pages, much to my present-day shame :(.

My only thought about this change is that it no longer describes the return value at all, though perhaps you just want to remove the EOVERFLOW check. Should we also remove the check from the one driver as part of this? (And what do other drivers do, do they truncate? You were going to change it to write to an sbuf I thought at one point?)

Yes. I'd planned on documenting then, and cleaning up that one case because it won't be relevant.

I'm going to punt on this and instead do the full conversion.