On Fri, Oct 07, 2011 at 03:26:21PM +0530, Himanshu Chauhan wrote:

On Thu, Oct 06, 2011 at 11:52:37PM -0700, Greg KH wrote:

quoted

On Fri, Oct 07, 2011 at 12:12:40PM +0530, Himanshu Chauhan wrote:

quoted

On Thu, Oct 06, 2011 at 12:07:52PM -0700, Guenter Roeck wrote:

quoted

And why, and what for.

The initial idea of posting to kernelnewbies was to get a hint on how
the patch would be taken as. I wanted to know if developers will like
the idea behind it or not. I guess, Guenter is not convinced with
any of my reasoning. I am willing to clean it up further only if
I get a positive hint. But it doesn't seem to be going anywhere.

Thanks Guenter, Alan, and Greg for taking your time and reviewing it.

Greg: To answer your last question, if this was taken positively, I
was thinking of having functionality similar to misc device registration.

But why?  What is that device node going to be used for?  Who would be
using it in userspace and where would it be tied into in the kernel?

The device node, as I said earlier, can be used for doing IOCTLS.

It can?  Which ones?  New ones you want to propose?  If so, why use an
ioctl?

In user space, applications that manage and monitor system environment
will need to use this interface for querying the sensor's location,
for example. In side the kernel, the driver that is driving the
particular hardware sensor can register a char interface for all this
and then register with hwmon with the same major/minor for usual sysfs
export of data.

So you are creating a new user/kernel api here, right?  If so, you need
to document it in Documentation/API and we need to be able to approve
that BEFORE we could ever accept the creation of new device nodes like
this, that at the moment, do not do anything.

In other words, you need to prove you need a new ioctl interface before
you can get a patch accepted that implements this.

greg k-h