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