All of lore.kernel.org
 help / color / mirror / Atom feed
From: yani.ioannou@gmail.com (Yani Ioannou)
To: lm-sensors@vger.kernel.org
Subject: [RFC PATCH 2.6.12-rc3] dynamic driver sysfs callbacks and RFC on
Date: Thu, 19 May 2005 06:25:56 +0000	[thread overview]
Message-ID: <25381867050504121679a9feba@mail.gmail.com> (raw)
In-Reply-To: <2538186705042422366584aff4@mail.gmail.com>

> > I've included a modified version of the previous dynamic callback
> > patch where I defined a DEVICE_ATTR_DATA macro which becomes useful in
> > these cases, likely in any real patch this would be rolled into the
> > DEVICE_ATTR macro but for simplicity (i.e. not breaking everything
> > else that uses DEVICE_ATTR out there) I'm using a separate one for
> > now.
> 
> Try modifying __ATTR() to have the data pointer and then make
> DEVICE_ATTR pass a NULL for the data field.
> 

This would work except __ATTR is used by all the attribute macros not
just DEVICE_ATTRIBUTE. Would a void * field in those attributes be
useful too?

> Just use the void * as an int.  No need to point it to an integer
> variable, right?  Would that make this code a bit more readable (it's
> pretty messy as is.)
Jean:
On 5/4/05, Jean Delvare <khali@linux-fr.org> wrote:
>Irk. What about the kittens? :(

I was tempted to do this but it set off alarms in my better coding
judgement (abusing a pointer to store an int). It is certainly
'cleaner' than defining the awkward static ints, but aside from the
language abuse would doing something like this cause any portability
issues? And yes, what about those poor kittens? ;-)

> Hm, as we want to move toward dynamic attributes, would a helper
> function to create one be a good idea to have?
> 
It would be useful for most of the cases (like moving to dynamic
attributes in adm1026), but when creating completely dynamic
attributes (as in you don't know what you will be creating at compile
time) you have to create and allocate the sysfs name strings too (see
bmcsensors).

> And thanks for doing this, it makes a bit more sense now, and seems
> almost reasonable.  I'd like a few more cleanups before adding it to my
> trees :)
>

Well I'm an almost reasonable person ;-). Yes this code was mainly for
comment so it definitely needs cleaning up, although any pointers on
how/where are welcome.

Thanks,
Yani

  parent reply	other threads:[~2005-05-19  6:25 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19  6:25 [RFC PATCH 2.6.12-rc3] dynamic driver sysfs callbacks and RFC on Yani Ioannou
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Jean Delvare
2005-05-19  6:25 ` Dmitry Torokhov
2005-05-19  6:25 ` Dmitry Torokhov
2005-05-19  6:25 ` Grant Coady
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Jean Delvare
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Dmitry Torokhov
2005-05-19  6:25 ` Grant Coady
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Dmitry Torokhov
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Grant Coady
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Yani Ioannou [this message]
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Jean Delvare
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Greg KH
2005-05-19  6:25 ` Dmitry Torokhov
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` [RFC PATCH 2.6.12-rc3] dynamic driver sysfs callbacks and RFC Jean Delvare
2005-05-19  6:25 ` [RFC PATCH 2.6.12-rc3] dynamic driver sysfs callbacks and RFC on Greg KH
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Jean Delvare
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Yani Ioannou
2005-05-19  6:25 ` Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25381867050504121679a9feba@mail.gmail.com \
    --to=yani.ioannou@gmail.com \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.