7

I'm making a small kernel module to provide user-space access to some kernel-mode only features of an ARMv7 chip (specifically, cache control). I'm reading through Linux Device Drivers by Corbet, Rubini, and Hartman. In it they describe how to make a full driver+device+bus. I don't want to create a bus driver at all. In fact the 'driver' that I'm making doesn't really need to match against a device definition at all - it is implicitly matched to the platform's CPU. Can anyone explain to me:

  1. Where in sysfs should my attributes go? Should it be in my module entry under /sysfs/modules/mymodule? /sys/devices/platform seems promising too, and so does /sys/devices/system/cpu.
  2. If there is an existing place where I should put my kobject/attributes, how do I plug it into it? How do I get the necessary kset? All the examples I've seen create a kset and then link to it from the kobject - I haven't seen an API for requesting an existing named kset?

Sorry if this is just impossibly obvious, or if there's some really straightforward and easily discovered example somewhere that I haven't discovered for some reason. Can anyone shed any light on this?

Ted Middleton
  • 6,859
  • 10
  • 51
  • 71

1 Answers1

8

I haven't worked with sysfs much, but I found a simple-looking example that's pretty similar to what you are doing (naturally, it's also under ARM). Take a look at arch/arm/mach-omap1/pm.c, specifically the idle_show/idle_store sysfs file. It gets registered (using sysfs_create_file()) as /sys/power/sleep_while_idle and uses the global /sys/power kobj (defined in include/linux/kobject.h). There are a few other global kobj's defined there that you could use, although I'm don't think any are a good fit for your driver.

Is this going to be a platform driver? As a driver that doesn't fit under any bus, it seems like a good fit. Platform drivers get their own directory under /sys/devices/platform, and can have attributes there. Take a look at drivers/hwmon/coretemp.c, which has temp1_crit, temp1_crit_alarm, temp1_input, etc. as attributes. It looks fairly simple: create the attributes (maybe with __ATTR()?), list them all in an array, define an attribute_group, register it with sysfs_create_group() in the probe() function, and unregister it with sysfs_remove_group() in the remove() function.

There are probably other platform drivers that define attributes (search for sysfs_create_group) if you need other examples. Hope this helps!

Brendan Shanks
  • 3,141
  • 14
  • 13