On Wed, Nov 28, 2018 at 1:36 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > So you still need a char device, and you will have have a load of them, > just use the misc device api. It's simple, clean, and is hard to get > wrong. The cdev api is hard, complex, and trivial to get wrong in any > number of different ways that it can be used :) Awesome little nugget! These things you just can't tell by reading the kernel tree. In many cases, it's not immediately obvious to me which of the various methods are 'recommended', and which ones are historic leftovers. > And your /sys/class/fieldbus_dev/ is "interesting", why name it that? Not sure why it's interesting? I figured it would allow userspace to enumerate all fieldbus devices simply by going to /sys/class/fieldbus_dev/ and process every subdirectory. Example with 3 fieldbus cards: /sys/class/fieldbus_dev/fieldbus_dev0/name etc /sys/class/fieldbus_dev/fieldbus_dev1/name etc /sys/class/fieldbus_dev/fieldbus_dev2/name etc Is there a better way? > So keep submitting, I'll try to review it the next time around, and all > should be fine. But keep your user api as simple as possible for now, > only doing what you need it to do, worry about future stuff then. Thanks, that's awesome !! I figured that I should take baby steps. I simplified the userspace API to the absolute bare minimum. To the point that the profinet card isn't useable in our company's specific use case, because there's no configuration API yet. > Why not just /sys/class/fieldbus/ ? No need for "dev", right? Good question... Two very different classes of devices sit on a fieldbus: Fieldbus device is like a slave Fieldbus controller is like a master This subsystem is specific for fieldbus *devices*. I figured I'd encode this in the API name, in case someone wants to support fieldbus controllers later.
