Can I nest kobjects to create directories under parent directories for my driver?

Can I nest kobjects to create directories under parent directories for my driver?

[Kumba]

So I'm attempting to write my first kernel driver for an RTC chip (Dallas/Maxim 
DS1685/DS1687), and running into a problem with using sysfs properly.  First 
off, a patch for this specific RTC was sent int to rtc-linux about two years 
ago, but never made it anywhere.  I based off of that and have pretty much 
re-written the thing since then.  It's undergoing a second re-write after some 
initial feedback from the rtc-linux folks.

What I'm trying to do, is, in sysfs, create individual attributes for the bits 
in each control register.  DS1685 defines 6 control registers (4 are the 
standard DS1286-style, and 2 are "extended" in another address bank).

I want to organize it such that:

# ls /sys/devices/platform/rtc-ds1685/
driver@  misc/  modalias  nvram  regs/  rtc/  subsystem@  uevent

And in regs/:
ctrla/  ctrlb/  ctrlc/  ctrld/  ctrl4a/  ctrl4b/

And under each register folder, the available bits for that register.  When 
read, each bit returns either a 0 or a 1, and certain bits can be made writable 
to change their values.

So I started investigating how to do this.  I first got it setup such that the 
ctrla through ctrl4b folders appeared in the top-level folder 
(/sys/devices/platform/rtc-ds1685).  Reading/writing to those worked fine.  But 
when I changed my code to nest those attribute groups under a "regs" kobject, 
any attempt to read or write the registers resulted in an Oops (or unaligned 
access, page fault, etc).

So far, I've determined that by attaching the "regs" kobject to the parent 
dev->kobj, and then attaching each attribute group kobject to the "regs" 
kobject, I lose the reference to the device structure holding all the relevant 
data for the RTC.  Thus, when I try to readb() or writeb() the RTC registers, I 
hit a NULL pointer and its lights out.

So I know I'm doing it wrong.  Question is, how can I do it right?  I've already 
looked into (and tried) ksets.  I'm not setting those up properly because I run 
into the same issue in the custom "show" function I have to write out where I 
don't have a valid reference to the live device structure.

I've gone through the kobject and kset examples, polled through quite a few 
drivers (some in drivers/rtc, some elsewhere), and looked over the sysfs, 
kobject, and device headers.  But because I'm still learning, I'm not 100% what 
I need to look for to accomplish this.  Everything else in the driver mostly 
works.  All this kobject debugging pointed out a few improper uses of spinlocks, 
and I optimized some other bits, but by and large, this thing is about ready to 
ship to rtc-linux for review (again).

I should add, I'm developing this on an SGI O2 (mips), which actually uses one 
of these RTCs.  The O2 currently taps into the rtc-cmos driver, which appears to 
provide baseline functionality.  None of my debugging points at flaws in the 
mips base or in the RTC system, so I'm directing my inquiry here to see if 
anyone has advice I can use to get this working.

Are ksets what I need to use, or can I nest kobjects together to accomplish 
things?  Or is there another way that I need to study up on?


Thanks!

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org

"The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: Can I nest kobjects to create directories under parent directories for my driver?

[Greg KH]

On Mon, Feb 28, 2011 at 10:31:48PM -0500, Kumba wrote:
> So I'm attempting to write my first kernel driver for an RTC chip
> (Dallas/Maxim DS1685/DS1687), and running into a problem with using
> sysfs properly.  First off, a patch for this specific RTC was sent
> int to rtc-linux about two years ago, but never made it anywhere.  I
> based off of that and have pretty much re-written the thing since
> then.  It's undergoing a second re-write after some initial feedback
> from the rtc-linux folks.
> 
> What I'm trying to do, is, in sysfs, create individual attributes
> for the bits in each control register.  DS1685 defines 6 control
> registers (4 are the standard DS1286-style, and 2 are "extended" in
> another address bank).
> 
> I want to organize it such that:
> 
> # ls /sys/devices/platform/rtc-ds1685/
> driver@  misc/  modalias  nvram  regs/  rtc/  subsystem@  uevent
> 
> And in regs/:
> ctrla/  ctrlb/  ctrlc/  ctrld/  ctrl4a/  ctrl4b/

That's nice, but it really isn't a good idea to do things this deep.
Userspace tools will not be able to find things properly (like libudev)
and your kernel code will get very messy (as you have found out.)

Why not look at how the other rtc drivers work, they don't nest things
this deep and you need to sick with the standard userspace api and not
invent a new one if at all possible.

But to answer your question, you can do this, but I strongly discourage
it.

good luck,

greg k-h

Re: Can I nest kobjects to create directories under parent directories for my driver?

[Kumba]

On 03/02/2011 15:38, Greg KH wrote:
>
> That's nice, but it really isn't a good idea to do things this deep.
> Userspace tools will not be able to find things properly (like libudev)
> and your kernel code will get very messy (as you have found out.)
>
> Why not look at how the other rtc drivers work, they don't nest things
> this deep and you need to sick with the standard userspace api and not
> invent a new one if at all possible.
>
> But to answer your question, you can do this, but I strongly discourage
> it.

 From the way sysfs seems to work, I can see that it encourages as little 
nesting as possible.  So this is probably the way I will go and just call the 
entries "regs_ctrla" through "regs_ctrl4b".  It still conveys the relevant 
information and is easily doable through the existing userspace framework.

How does one nest kobjects, though?  Are ksets the only real way?  Or is it 
doable through linking kobjects to each other?  If the latter is possible, how 
does one keep the reference to the device structure intact?  I figure the right 
use of backcasting (through container_of) is one way, but it definitely seems 
like I am treading new territory with such an approach.

I did learn one useful thing through this -- the use of a common show/store 
function for each register (using strncmp to look up which bit was accessed).  I 
was originally doing a single show/store pair for each, which added major code 
bloat and resulted in a ~80kb+ module.

Thanks for the feedback!  Thought my message had gotten lost!

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org

"The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: Can I nest kobjects to create directories under parent directories for my driver?

[Greg KH]

On Wed, Mar 02, 2011 at 04:49:14PM -0500, Kumba wrote:
> On 03/02/2011 15:38, Greg KH wrote:
> >
> >That's nice, but it really isn't a good idea to do things this deep.
> >Userspace tools will not be able to find things properly (like libudev)
> >and your kernel code will get very messy (as you have found out.)
> >
> >Why not look at how the other rtc drivers work, they don't nest things
> >this deep and you need to sick with the standard userspace api and not
> >invent a new one if at all possible.
> >
> >But to answer your question, you can do this, but I strongly discourage
> >it.
> 
> From the way sysfs seems to work, I can see that it encourages as
> little nesting as possible.

No, not at all, just you don't want to do nesting "on your own".

> So this is probably the way I will go
> and just call the entries "regs_ctrla" through "regs_ctrl4b".  It
> still conveys the relevant information and is easily doable through
> the existing userspace framework.

That's good.

But again, please look at how other rtc drivers did this so you aren't
creating an api that is unique.

> How does one nest kobjects, though?  Are ksets the only real way?

First off, a driver should _never_ need to deal with a kobject.  Or a
struct device even, that's up to the bus code to wrap up, and even then,
it doesn't deal with kobjects.

You nest 'struct device' objects, as they nest very easy and is how the
kobject stuff is implemented for "real" devices in the kernel.

> Or is it doable through linking kobjects to each other?  If the
> latter is possible, how does one keep the reference to the device
> structure intact?  I figure the right use of backcasting (through
> container_of) is one way, but it definitely seems like I am treading
> new territory with such an approach.

You can do it on your own, but it's tricky, and I don't recommend it at
all, especially in a driver.  Actually never in a driver, just don't do
it.

But if you are curious, look at the kobject documentation in the kernel
tree.  It has working examples and hopefully everything you need if you
are curious.

But again, don't do it, your code will be rejected :)

> I did learn one useful thing through this -- the use of a common
> show/store function for each register (using strncmp to look up
> which bit was accessed).  I was originally doing a single show/store
> pair for each, which added major code bloat and resulted in a ~80kb+
> module.

Yes, that is a nice thing to make code smaller.

thanks,

greg k-h