Skip to content

libuutil: purge vestigia #11873

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Apr 12, 2021
Merged

libuutil: purge vestigia #11873

merged 3 commits into from
Apr 12, 2021

Conversation

nabijaczleweli
Copy link
Contributor

@nabijaczleweli nabijaczleweli commented Apr 9, 2021

Motivation and Context

See individual commit messages, #11866

Description

All-minus diffstat, babey

For later reference – used 's:/home/nabijaczleweli/store/code/zfs:/home/fedora/zfs:;s:/usr/lib/llvm-13/lib/clang/13.0.0/include/:/usr/lib/gcc/x86_64-redhat-linux/10/include/:;s:/usr/include/x86_64-linux-gnu/bits/:/usr/include/bits/:' to filter the ABI

How Has This Been Tested?

I mean, it builds?

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Performance enhancement (non-breaking change which improves efficiency)
  • Code cleanup (non-breaking change which makes code smaller or more readable)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv) – I haven't bumped the -version-info because I don't know what to?
  • Documentation (a change to man pages or other documentation)

Checklist:

  • My code follows the OpenZFS code style requirements.
  • I have updated the documentation accordingly.
  • I have read the contributing document.
  • I have added tests to cover my changes.
  • I have run the ZFS Test Suite with this change applied. — CI take my hand
  • All commit messages are properly formatted and contain Signed-off-by.

Copy link
Contributor

@behlendorf behlendorf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to shed this dead never used code. This just needs a rebase to resolve the conflict.

@behlendorf behlendorf added the Status: Accepted Ready to integrate (reviewed, tested) label Apr 11, 2021
The follow-log so far is such:
  commit e5dc681
  Author: Ricardo M. Correia <[email protected]>
  Date:   Thu Aug 26 09:52:40 2010 -0700

      Fix gcc ident pragma warnings

      Remove all ident pragmas which are unknown to gcc.

      Signed-off-by: Brian Behlendorf <[email protected]>

  commit 172bb4b
  Author: Brian Behlendorf <[email protected]>
  Date:   Thu Dec 11 11:08:09 2008 -0800

      Move the world out of /zfs/ and seperate out module build tree

  commit b128c09
  Author: Brian Behlendorf <[email protected]>
  Date:   Wed Dec 3 12:09:06 2008 -0800

      Rebase to OpenSolaris b103, in the process we are removing any
      code which did not originate from the OpenSolaris source.
      These changes will be reintroduced in topic branches
      for easier tracking

  commit 34dc7c2
  Author: Brian Behlendorf <[email protected]>
  Date:   Thu Nov 20 12:01:55 2008 -0800

      Initial Linux ZFS GIT Repo

That, in reverse order:
  1. add this file
  2. add a #pragma ident
  3. move it
  4. remove that #pragma ident

The problems with this implementation are many, but the primary one is
the TMPPATHFMT macro, which is unused, and always has been

Searching around for any users leads only to earlier imports of the
same, identical file, i.a. into an apple repository (which does patch
gethrtime() into it and gives us a copyright date of 2007),
and a MidnightBSD one from 2008

Searching illumos-gate, uu_open_tmp appears, in current HEAD, three
times: in the header, libuutil's mapfile ABI, and the implementation

This slowly grows up to eight occurrences as one moves back to the root
"OpenSolaris Launch" commit: the header, implementation, twice in
libuutil's spec ABI, twice (with multilib and non-multilib paths) in
libuutil.so's i386 and SPARC binary db ABIs

That's 2005, and this file was abandonware /even then/ ‒
it's dead code, rotting for the past sixteen years at /least/

Signed-off-by: Ahelenia Ziemiańska <[email protected]>
Similar situation as uu_open_tmp(), except it got caught by coverity
once before and also appears in a FreeBSD build log

Signed-off-by: Ahelenia Ziemiańska <[email protected]>
Similar story ‒ nothing in accessibly recorded history has ever used it

Signed-off-by: Ahelenia Ziemiańska <[email protected]>
@nabijaczleweli
Copy link
Contributor Author

Rebased

@behlendorf behlendorf merged commit 722b7f9 into openzfs:master Apr 12, 2021
mcmilk pushed a commit to mcmilk/zfs that referenced this pull request Apr 15, 2021
Remove vestigial uu_open_tmp().  The problems with this implementation
are many, but the primary one is the TMPPATHFMT macro, which is
unused, and always has been.

Searching around for any users leads only to earlier imports of the
same, identical file, i.a. into an apple repository (which does patch
gethrtime() into it and gives us a copyright date of 2007),
and a MidnightBSD one from 2008.

Searching illumos-gate, uu_open_tmp appears, in current HEAD, three
times: in the header, libuutil's mapfile ABI, and the implementation.

This slowly grows up to eight occurrences as one moves back to the root
"OpenSolaris Launch" commit: the header, implementation, twice in
libuutil's spec ABI, twice (with multilib and non-multilib paths) in
libuutil.so's i386 and SPARC binary db ABIs.

That's 2005, and this file was abandonware even then, it's dead code.

The situation is similar for the uu_dprintf() family of functions and
uu_dump().  Nothing in accessibly recorded history has ever used them.

Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: Ahelenia Ziemiańska <[email protected]>
Closes openzfs#11873
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants