On Sat, Sep 12, 2026 at 10:02:12AM -0700, Stephen Hemminger wrote: > After reviewing lots of drivers and seeing sloppy string handling > resorted to AI assistance to unify and consolidate the parsing > of sysfs values. Many drivers open code this with similar pattern > but lacked any coherent error handling. The kernel API is > consistent and won't give bad data, but it make sense to > check for garbage. > > Add one set of routines in EAL that build the path from a printf > style format and convert with strtoul()/strtol(), then convert the > existing callers. > > Since the new routines are Linux only, a driver that uses sysfs while > advertising support on FreeBSD or Windows now fails to link. Two such > cases turned up and are fixed here: the eal_fs test and common/ionic. > > Note: existing eal_parse_sysfs_value() goes away with this. > It was exported as a stable symbol, which was a mistake: > the eal_ prefix and the private eal_filesystem.h both say it is internal, > and nothing outside the tree should have been calling it. > The new rte_sysfs_parse_XXX routines are exported, but marked > as internal use only. > > v2 - checkpatch fixes > - clang format attribute fix > - sysfs is Linux only, not unix > > Stephen Hemminger (9): > eal: add common sysfs value routines > dma/idxd: use common sysfs routines > common/ionic: use common sysfs routines > bus/vmbus: use common sysfs routines > power: use common sysfs routines > drivers/bus: remove duplicate sysfs string helpers > common/mlx5: use common sysfs routines > net/mlx5: use common sysfs routines > net/mana: use common sysfs routines > Agree with this change in general, and I just ran a regession test with dma/idxd driver, which reads a number of values from sysfs, and all seems ok.
One question, what way is the patchset being split up? Some drivers are separated out into patches 2-9, while other drivers are being updated in patch 1?
