There should be no print's in init functions

[rminnich]

Describe the issue

In the clock code for linux, there is a print.

This means that any command that includes this package will have a spurious print. This is a big problem
for, e.g, u-root.

Expected behavior

The package should not print.

Minimal code example to reproduce the issue

include this package in an command (u-root/cmds/exp/tc is an example). Run it. Note that on some kernels
it will print.

Consider make the two clocks variables functions and using once.Do to read the file in /proc.
You might also want to have a Must variant indicating that the variables must come from /proc.

In any event, there should not be a print function in an init() function in a package.

[florianl]

Hi @rminnich
thanks for reporting this issue. Do you have a particular API in mind, that you would like to see?
When writing this part of the code, it was expected that /proc/net/psched always exists.

[florianl]

With #259 I went with a different approach than the suggested one. Would this interface approach also fit you @rminnich ?

[rminnich]

psched might frequently exist, but in tiny kernels, it does not. Print in a package is a no-no, but print in an init is even more of a no-no. Somehow this code needs to quietly accomodate that file not existing.

I think you need a design that allows calling that function to be optional, not done via init(), and not having a printf in it.
Packages that print cause all kinds of problem in CI, among other things.

Maybe a once.Do for readPsched in tc.Open would do it. You might need a Must pattern for people who demand that psched exist, but since it all seems to work without psched, maybe no error is needed?

I kind of also feel the name go-tc is not necessary, tc would probably be fine. But it's probably too late for that :)

[florianl]

Thanks for the feedback. Closing with the merge of #261. Also a new tag was pushed, to make it easier to include this change.