Re: Right way to configure a driver? (sysfs, ioctl, proc, configfs,....)

[Greg KH <greg@kroah.com>]

On Fri, Jan 27, 2006 at 11:30:26AM +0100, Aritz Bastida wrote:
> Hi!
> 
> > Hope this helps,
> >
> > greg k-h
> >
> 
> Yes, it helped me much. I'll move all the configuration/statistics to
> sysfs. I will read carefully the corresponding chapter in LDD3 :)
> But before that, I've got a few questions with what I know:
> 
> 1.- In what directory should I do all this configuration? I guess as,
> I'm writing a module it should be in /sys/module/<my_module>, right?
> Or would your recommend /sys/class/net or anything?

Your device directory is usually the best for device specific options.
In your driver directory (for the type of bus driver that your device
lives on) is for driver-wide options.

Not in the module directory, that's not easy to get to and not
recommended at all.  Only module paramaters go there.

> 2.- In my sysfs directory I would create two subdirectories: "config"
> and "stats". In the first I would place read/write files used for
> configuration. For example "config/flags" for the flags variable. In
> the second read-only files with the statistics. Is this approach
> correct?

The config stuff might be better off in configfs, not sysfs.

> 3.- Actually the most difficult config I must do is to pass three
> values from userspace to my module. Specifically two integers and a
> long (it's an offset to a memory zone I've previously defined)
> 
> struct meminfo {
>         unsigned int      id;         /* segment identifier */
>         unsigned int      size;     /* size of the memory area */
>         unsigned long   offset;   /* offset to the information */
> };
> 
> How would you pass this information in sysfs? Three values in the same
> file? Note that using three different files wouldn't be atomic, and I
> need atomicity.

Use configfs.

> 4.- Last, you suggested that I had three files for the rx_packets count:
>       rx_packets_cpu0
>       rx_packets_cpu1
>       rx_packets_total
> 
>      I have quite a few counters, and if that number of files is multiplied by
>      the number of cpus, the number of files could be very large (imagine a
>      8-cpu box), don't you think so? And after all reading a file with three
>      values could be done very easily with awk...

So, lots of files is not a problem, have you looked at the sysfs file
entries for the sensor/hwmon drivers in a while?  There are zillions of
them :)

thanks,

greg k-h