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)

2. Get rid of the receivers, if possible:

- func (fs FS) parseFoo() (Foo, error)
+ func parseFoo() (Foo, error)

3. 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)

• Separate NetStat parsing logic
• Separate /proc/stat parsing logic
• Separate /proc/stat disk stat parsing logic
• ...

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