All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Himanshu Chauhan <hschauhan@nulltrace.org>,
	lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH] hwmon class driver registration with a
Date: Thu, 06 Oct 2011 07:43:02 +0000	[thread overview]
Message-ID: <20111006094302.71ea4dfd@endymion.delvare> (raw)
In-Reply-To: <20111006051955.GA22835@ericsson.com>

I am purposely removing kernelnewbies from the CC list, as it seems
quite irrelevant for this discussion.

On Wed, 5 Oct 2011 22:19:55 -0700, Guenter Roeck wrote:
> On Thu, Oct 06, 2011 at 12:06:59AM -0400, Himanshu Chauhan wrote:
> > Hi,
> > 
> > > I can not comment on the merits of your patch. Unless I am missing
> > > something, which may well be since I only spent a couple of minutes on
> > > it, other device classes don't seem to provide a similar API, so I don't
> > > know if or why it would make sense for hwmon. Maybe a driver which wants
> > > to register a character device interface should do so independently of
> > > hwmon.
> > > 
> > 
> > The idea here is to sit in the same class directory as of hwmon. Devices
> > registered with this interface will have "dev" under, for example,
> > /sys/class/hwmon/hwmon0/dev. To do the same inside the driver will be
> > a bit more involved than a call.
> > 
> > In my opinion other classes should also have similar interfaces.
> > 
> I think you'll have to spend some more time and effort explaining the "what for".
> 
> Apparently no other device class needs this functionality so far, yet you
> suggest that such an interface should exist for all device classes.

Actually a lot of class devices do have a device node:
$ ls -1 /sys/class/*/*/dev | wc -l
252
This includes block, drm, dvb, input, msr, sound and tty class devices,
to name just a few. But this isn't the problem. All these are
documented in Documentation/devices.txt, and have a properly defined
API. There is no such thing for hwmon devices at this point.

> But you do so without explanation, or in other words without use case.

This is indeed the key point. Creating a device node is pointless
without a standard API to make use of it. So Himanshu will have to
document that first.

> I for my part have no idea what you would use or need this new interface for,
> and if there would be other less intrusive means to accomplish the same goal.
> And I would want to see really good reasons to make a change like this.

Another good point.

> Specifically looking at the hwmon subsystem, you are expected to use the lm-sensors
> library to access all hwmon attributes. So I would expect your explanation to include
> exactly what you want to accomplish and why, details why you believe that you can not
> use the lm-sensors library, why you believe that the current infrastructure
> does not provide the means you need to accomplish your goals, and why you
> think that the existing infrastructure can not be modified to let you accomplish
> what you want to do without such a - from a conceptual perspective - substantial change.

I again agree. Which means that Himanshu is still 3 steps away from
getting his patch accepted:
* Explaining why the current sysfs interface is insufficient and can't
  be fixed.
* Getting official device node numbers registered for hwmon use.
* Defining an API for these device nodes.

Before then, there's no point in resending this patch, it will be
rejected.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Himanshu Chauhan <hschauhan@nulltrace.org>,
	lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH] hwmon class driver registration with a  device number
Date: Thu, 6 Oct 2011 09:43:02 +0200	[thread overview]
Message-ID: <20111006094302.71ea4dfd@endymion.delvare> (raw)
In-Reply-To: <20111006051955.GA22835@ericsson.com>

I am purposely removing kernelnewbies from the CC list, as it seems
quite irrelevant for this discussion.

On Wed, 5 Oct 2011 22:19:55 -0700, Guenter Roeck wrote:
> On Thu, Oct 06, 2011 at 12:06:59AM -0400, Himanshu Chauhan wrote:
> > Hi,
> > 
> > > I can not comment on the merits of your patch. Unless I am missing
> > > something, which may well be since I only spent a couple of minutes on
> > > it, other device classes don't seem to provide a similar API, so I don't
> > > know if or why it would make sense for hwmon. Maybe a driver which wants
> > > to register a character device interface should do so independently of
> > > hwmon.
> > > 
> > 
> > The idea here is to sit in the same class directory as of hwmon. Devices
> > registered with this interface will have "dev" under, for example,
> > /sys/class/hwmon/hwmon0/dev. To do the same inside the driver will be
> > a bit more involved than a call.
> > 
> > In my opinion other classes should also have similar interfaces.
> > 
> I think you'll have to spend some more time and effort explaining the "what for".
> 
> Apparently no other device class needs this functionality so far, yet you
> suggest that such an interface should exist for all device classes.

Actually a lot of class devices do have a device node:
$ ls -1 /sys/class/*/*/dev | wc -l
252
This includes block, drm, dvb, input, msr, sound and tty class devices,
to name just a few. But this isn't the problem. All these are
documented in Documentation/devices.txt, and have a properly defined
API. There is no such thing for hwmon devices at this point.

> But you do so without explanation, or in other words without use case.

This is indeed the key point. Creating a device node is pointless
without a standard API to make use of it. So Himanshu will have to
document that first.

> I for my part have no idea what you would use or need this new interface for,
> and if there would be other less intrusive means to accomplish the same goal.
> And I would want to see really good reasons to make a change like this.

Another good point.

> Specifically looking at the hwmon subsystem, you are expected to use the lm-sensors
> library to access all hwmon attributes. So I would expect your explanation to include
> exactly what you want to accomplish and why, details why you believe that you can not
> use the lm-sensors library, why you believe that the current infrastructure
> does not provide the means you need to accomplish your goals, and why you
> think that the existing infrastructure can not be modified to let you accomplish
> what you want to do without such a - from a conceptual perspective - substantial change.

I again agree. Which means that Himanshu is still 3 steps away from
getting his patch accepted:
* Explaining why the current sysfs interface is insufficient and can't
  be fixed.
* Getting official device node numbers registered for hwmon use.
* Defining an API for these device nodes.

Before then, there's no point in resending this patch, it will be
rejected.

-- 
Jean Delvare

  reply	other threads:[~2011-10-06  7:43 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-05 17:13 [PATCH] hwmon class driver registration with a device number Himanshu Chauhan
2011-10-05 17:13 ` Himanshu Chauhan
2011-10-05 18:30 ` [lm-sensors] [PATCH] hwmon class driver registration with a Guenter Roeck
2011-10-05 18:30   ` [PATCH] hwmon class driver registration with a device number Guenter Roeck
2011-10-06  4:06   ` Himanshu Chauhan
2011-10-06  4:18     ` [lm-sensors] [PATCH] hwmon class driver registration with a Himanshu Chauhan
2011-10-06  4:06     ` [PATCH] hwmon class driver registration with a device number Himanshu Chauhan
2011-10-06  5:19     ` [lm-sensors] [PATCH] hwmon class driver registration with a Guenter Roeck
2011-10-06  5:19       ` [PATCH] hwmon class driver registration with a device number Guenter Roeck
2011-10-06  7:43       ` Jean Delvare [this message]
2011-10-06  7:43         ` [lm-sensors] " Jean Delvare
2011-10-06 15:12         ` Himanshu Chauhan
2011-10-06 15:24           ` [lm-sensors] [PATCH] hwmon class driver registration with a Himanshu Chauhan
2011-10-06 15:46           ` Alan Cox
2011-10-06 15:46             ` [lm-sensors] [PATCH] hwmon class driver registration with a device number Alan Cox
2011-10-06 16:25             ` Himanshu Chauhan
2011-10-06 16:37               ` [lm-sensors] [PATCH] hwmon class driver registration with a Himanshu Chauhan
2011-10-06 15:15         ` Guenter Roeck
2011-10-06 15:15           ` [lm-sensors] [PATCH] hwmon class driver registration with a device number Guenter Roeck
2011-10-06 16:43           ` Himanshu Chauhan
2011-10-06 16:55             ` [lm-sensors] [PATCH] hwmon class driver registration with a Himanshu Chauhan
2011-10-05 19:33 ` [PATCH] hwmon class driver registration with a device number Greg KH
2011-10-05 19:33   ` Greg KH
2011-10-06  4:10   ` Himanshu Chauhan
2011-10-06  4:22     ` [lm-sensors] [PATCH] hwmon class driver registration with a Himanshu Chauhan
2011-10-06  4:10     ` [PATCH] hwmon class driver registration with a device number Himanshu Chauhan
2011-10-06 18:25     ` Greg KH
2011-10-06 18:25       ` Greg KH
2011-10-06 18:25       ` [lm-sensors] [PATCH] hwmon class driver registration with a Greg KH
2011-10-06 19:07       ` Guenter Roeck
2011-10-06 19:07         ` [lm-sensors] [PATCH] hwmon class driver registration with a device number Guenter Roeck
2011-10-07  6:42         ` Himanshu Chauhan
2011-10-07  6:54           ` [lm-sensors] [PATCH] hwmon class driver registration with a Himanshu Chauhan
2011-10-07  6:42           ` [lm-sensors] [PATCH] hwmon class driver registration with a device number Himanshu Chauhan
2011-10-07  6:52           ` Greg KH
2011-10-07  6:52             ` Greg KH
2011-10-07  6:52             ` [lm-sensors] [PATCH] hwmon class driver registration with a Greg KH
2011-10-07  9:56             ` [lm-sensors] [PATCH] hwmon class driver registration with a device number Himanshu Chauhan
2011-10-07 10:08               ` [lm-sensors] [PATCH] hwmon class driver registration with a Himanshu Chauhan
2011-10-07  9:56               ` [lm-sensors] [PATCH] hwmon class driver registration with a device number Himanshu Chauhan
2011-10-07 11:11               ` [lm-sensors] [PATCH] hwmon class driver registration with a Jonathan Cameron
2011-10-07 11:11                 ` [lm-sensors] [PATCH] hwmon class driver registration with a device number Jonathan Cameron
2011-10-07 15:46               ` Greg KH
2011-10-07 15:46                 ` Greg KH
2011-10-07 15:46                 ` [lm-sensors] [PATCH] hwmon class driver registration with a Greg KH

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=20111006094302.71ea4dfd@endymion.delvare \
    --to=khali@linux-fr.org \
    --cc=guenter.roeck@ericsson.com \
    --cc=hschauhan@nulltrace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.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.