> You have to implement it once on kernel side and once in userspace
I actually did think about this before posting my original response, and I think this is unrealistic from a practical perspective. To elaborate a bit on that:
First of, a one-size-fits-all structured format is a lot more complex than a directory with ASCII files in it that each store an integer and IMO invites itself to feature creep (i.e. more complexity).
Complexity is IMO the root cause of the issue originally discussed here (if not most bugs). The more code, the more complexity, the more bugs. In my experience, software will always have bugs, complex software more so.
There can never be a "one-true-implementation" for userspace. Because of the complexity, people will write their own ad-hoc versions. They "only need that one thing" and don't want to drag the whole library dependency in. Some people think they know better and write their own "lightweight/suckless/..." versions because the kernel one is "bloated", or "that API sucks". Some will rewrite it in their favorite programming language for whatever reason. NIH syndrome, bike shedding, ...
Then, what if a widely used implementation has a bug? Especially if it's the "one-true-library" itself? You now need to roll out a fix. Across countless Distros, embedded devices that might get maintenance updates every couple years at best, set-top boxes, network appliances, ... You'll have programs floating around that are statically linked against a specific version of the one-true-library. In the end, we have a variety of differently bugged parsers in use, simply because of the spread in versions alone. The original problem that we wanted to solve, remains.
Of course there are issues with the more simplistic approach, but in the case of e.g. sysfs, those are typically corner cases. Adding a one-size-fits-all special, structured format for everything introduces a whole lot of unneeded complexity everywhere else as well. A "one-true-format to solve all problems" that needs special library code for processing IMO introduces a whole lot more problems than it solves.
I actually did think about this before posting my original response, and I think this is unrealistic from a practical perspective. To elaborate a bit on that:
First of, a one-size-fits-all structured format is a lot more complex than a directory with ASCII files in it that each store an integer and IMO invites itself to feature creep (i.e. more complexity).
Complexity is IMO the root cause of the issue originally discussed here (if not most bugs). The more code, the more complexity, the more bugs. In my experience, software will always have bugs, complex software more so.
There can never be a "one-true-implementation" for userspace. Because of the complexity, people will write their own ad-hoc versions. They "only need that one thing" and don't want to drag the whole library dependency in. Some people think they know better and write their own "lightweight/suckless/..." versions because the kernel one is "bloated", or "that API sucks". Some will rewrite it in their favorite programming language for whatever reason. NIH syndrome, bike shedding, ...
Then, what if a widely used implementation has a bug? Especially if it's the "one-true-library" itself? You now need to roll out a fix. Across countless Distros, embedded devices that might get maintenance updates every couple years at best, set-top boxes, network appliances, ... You'll have programs floating around that are statically linked against a specific version of the one-true-library. In the end, we have a variety of differently bugged parsers in use, simply because of the spread in versions alone. The original problem that we wanted to solve, remains.
Of course there are issues with the more simplistic approach, but in the case of e.g. sysfs, those are typically corner cases. Adding a one-size-fits-all special, structured format for everything introduces a whole lot of unneeded complexity everywhere else as well. A "one-true-format to solve all problems" that needs special library code for processing IMO introduces a whole lot more problems than it solves.