Re: driverfs API Updates

From: Rusty Russell (rusty@rustcorp.com.au)
Date: Thu Aug 08 2002 - 20:20:07 EST


In message <Pine.LNX.4.44.0208080914060.1241-100000@cherise.pdx.osdl.net> you w
rite:
> That said, this is what I want to do:
>
> Define helpers for parsing and formatting types; e.g. show_int() and
> store_int(). Objects' show and store methods can use those for the exposed
> attribute.
>
> Support single static attributes by having something like this:
>
> struct int_attribute {
> struct attribute attr;
> show_int_t show;
> store_int_t store;
> int * data;
> };
>
> INT_ATTR(frobbable,0644);

Ok, that makes sense, except I prefer to build the interface in
layers, something like:

        ATTRIBUTE(frobbable,int,0644)
        => ATTRIBUTE_CALL(frobbable,0644,show_int,store_int)

This still allows you to define your own types...

> What do you think? It definitely looks a lot like your PARAM stuff, and I
> need to look again at what you wrote to see if I can tie in any more of
> it.

I think you've got all the good bits now 8)

> Of course, they don't have to be exposed to userspace in order to access
> them. This is a little further down the road, but by placing them (or
> pointers to them) in a special section, we could access attributes at boot
> time or module load time, like module parameters.

This was my idea with "000" perm attributes: they are explicitly only
settable at module/kernel init (eg. they and their set/show functions
can be declared __init).

> I'm thinking that we could macro-ize locking for single static variables
> as well. We could have something like:
>
> rwlock_t mylock;
>
> INT_ATTR_LOCKED(frobbable,0644,mylock);
>
> which could then generate
>
> int get_frobbable(void);
>
> void set_frobbable(int val);

Hmmm, how about:

        ATTRIBUTE_LOCKED(frobbable,int,0644,mylock)
        => ATTRIBUTE_CALL(frobbable,0644,mylock,show_int_lock,store_int_lock)

With PARAM()/sysfs, I hit the wall when I tried to handle spinlocks,
rwlocks, semaphores, rwsemaphores, and backed off until I knew which
ones were actually useful 8)

This is the nice thing about having people actually using the code is
you can tell when you've hit the 90% mark (the weird cases can always
use their own callbacks). I think trial-and-error is the best way to
introduce these kind of convenience functions.

Rusty.

--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:18 EST