prometheus / prometheus/procfs

Separate all parsing functions (or make public)

Open
#478 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
883
Forks
388
Avg merge
13h 28m
Merged PRs (30d)
3

Description

Motivation

As procfs already using parseX(io.Reader) functions for parsing proc filesystem files, some functions also do syscall to read the target file' content. The main pitfall of this is that procfs enforce us to use this package only on Linux. For the people who want to make some stuff using this package on other OS environments, it's slightly difficult.

Proposal
  • Separate core parsing functions: (i.e. os.Open and parsing logic should not be allowed in same function)
  • These functions should NOT do any syscall (or depend on)
  • All functions should accept an input arg: io.Reader or []byte
  • Returned data types should also be exported:

Example

  1. Make all output types exported:
- func parseFoo() (foo, error)
+ func parseFoo() (Foo, error)
  1. Get rid of the receivers, if possible:
- func (fs FS) parseFoo() (Foo, error)
+ func parseFoo() (Foo, error)
  1. Convert all parsing functions to public:
- func parseFoo() (Foo, error)
+ func ParseFoo() (Foo, error)
  • Some parser funcs might be depended on a receiver such as FS. If received is really required during the parsing stage, keep it as-is for now

1. If we about to keep those as private

Anyone who want to just access parser functions, have to use go:linkname directive as like the following:

//go:linkname parseLine github.com/prometheus/procfs.NetDev.parseLine
func parseLine(a procfs.NetDev, b string) (*procfs.NetDevLine, error)

2. If we about to keep those as Public

  • No need to use go:linkname directive
  • Better control over all functions

3. Depend on a receiver or some function that do syscalls

We simply have to do CTRL+C/CTRL+V the actual logic. Which is decreasing the overall UX of the package.

Tracking (Merge Status)

Waiting your thoughts! I can make this issue as a tracking issue, if it does make sense in overall!

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing PRs #472, #474, and #477, then use their parsing changes as entry points for the remaining procfs work. Inventory the parser functions covered by this tracking issue and compare them with the proposal’s input and export requirements. Done means the remaining scope is implemented or explicitly narrowed, with the tracking checklist updated.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
operating-systems
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.