From: gregkh@suse.de (Greg KH)
To: dtor_core@ameritech.net
Cc: johnpol@2ka.mipt.ru, sensors@stimpy.netroedge.com,
LKML <linux-kernel@vger.kernel.org>
Subject: [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes
Date: Thu, 19 May 2005 06:25:54 +0000 [thread overview]
Message-ID: <20050426065839.GD5889@suse.de> (raw)
In-Reply-To: <d120d50005042509326241a302@mail.gmail.com>
On Mon, Apr 25, 2005 at 11:32:14AM -0500, Dmitry Torokhov wrote:
> On 4/25/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > On Thu, 2005-04-21 at 09:31 -0500, Dmitry Torokhov wrote:
> > >
> > > OK, that is what I am aying. But why do you need that attribute with
> > > variable name and a bin attribute that is not really bin but just a
> > > dump for all kind of data (looks like debug one).
> >
> > bin attribute was created for lm_sensors scripts format - it only caches
> > read value.
> > I think there might be only 2 "must have" methods - read and write.
> > I plan to implement them using connector, so probably they will go away
> > completely.
> ...
> > > You will not be able to cram all 1-wire devices into unified
> > > interface. You will need to build classes on top of it and you might
> > > use connector (I am not sure) bit not on w1 bus level.
> > > ...
> >
> > connector allows to have different objects inside one netlink group,
> > so it will use it in that way.
> > I think only two w1 methods must exist - read and write,
> > and they must follow protocol, defined in family driver.
>
> No, I think there should not be any "must have" methods on w1_bus
> level. What you really need (and this needs to be coordinated with
> other sensors people) is a "sensors" class hierarchy that will define
> classes like "temperature sensor", "fan", "vid", etc. Then your w1
> family drivers, when bound to a slave, will create needed class
> devices. i2c drivers will do the same, and your superio, and I'll be
> able to change i8k driver just for kicks. Then your usespace would not
> care what _bus_ a particular sensor is sittign on and will be
> presented with a unified interface.
Yes, that is the way to go, and is what a number of people are currently
working on implementing.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@suse.de>
To: dtor_core@ameritech.net
Cc: johnpol@2ka.mipt.ru, sensors@stimpy.netroedge.com,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes
Date: Mon, 25 Apr 2005 23:58:39 -0700 [thread overview]
Message-ID: <20050426065839.GD5889@suse.de> (raw)
In-Reply-To: <d120d50005042509326241a302@mail.gmail.com>
On Mon, Apr 25, 2005 at 11:32:14AM -0500, Dmitry Torokhov wrote:
> On 4/25/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > On Thu, 2005-04-21 at 09:31 -0500, Dmitry Torokhov wrote:
> > >
> > > OK, that is what I am aying. But why do you need that attribute with
> > > variable name and a bin attribute that is not really bin but just a
> > > dump for all kind of data (looks like debug one).
> >
> > bin attribute was created for lm_sensors scripts format - it only caches
> > read value.
> > I think there might be only 2 "must have" methods - read and write.
> > I plan to implement them using connector, so probably they will go away
> > completely.
> ...
> > > You will not be able to cram all 1-wire devices into unified
> > > interface. You will need to build classes on top of it and you might
> > > use connector (I am not sure) bit not on w1 bus level.
> > > ...
> >
> > connector allows to have different objects inside one netlink group,
> > so it will use it in that way.
> > I think only two w1 methods must exist - read and write,
> > and they must follow protocol, defined in family driver.
>
> No, I think there should not be any "must have" methods on w1_bus
> level. What you really need (and this needs to be coordinated with
> other sensors people) is a "sensors" class hierarchy that will define
> classes like "temperature sensor", "fan", "vid", etc. Then your w1
> family drivers, when bound to a slave, will create needed class
> devices. i2c drivers will do the same, and your superio, and I'll be
> able to change i8k driver just for kicks. Then your usespace would not
> care what _bus_ a particular sensor is sittign on and will be
> presented with a unified interface.
Yes, that is the way to go, and is what a number of people are currently
working on implementing.
thanks,
greg k-h
next prev parent reply other threads:[~2005-05-19 6:25 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-21 7:07 [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:08 ` [RFC/PATCH 1/22] W1: whitespace fixes Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:08 ` [RFC/PATCH 2/22] W1: formatting fixes Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:09 ` [RFC/PATCH 3/22] W1: use attribute group for master's attributes Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:10 ` [RFC/PATCH 4/22] W1: use attribute group for slave's attributes Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:11 ` [RFC/PATCH 5/22] W1: list handling cleanup Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:13 ` [RFC/PATCH 6/22] W1: drop owner field from master and slave structures Dmitry Torokhov
2005-05-19 6:25 ` [RFC/PATCH 6/22] W1: drop owner field from master and slave Dmitry Torokhov
2005-04-21 7:13 ` [RFC/PATCH 7/22] W1: bus operations cleanup Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:15 ` [RFC/PATCH 8/22] W1: merge master code into one file Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:16 ` [RFC/PATCH 9/22] W1: drop custom hotplug over netlink notification Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:17 ` [RFC/PATCH 10/22] W1: drop main control thread Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:18 ` [RFC/PATCH 11/22] W1: move w1_search to the rest of IO code Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:19 ` [RFC/PATCH 12/22] W1: drop unneeded master attributes Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:20 ` [RFC/PATCH 13/22] W1: cleanup master attributes handling Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:21 ` [RFC/PATCH 14/22] W1: rename timeout to scan_interval Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:22 ` [RFC/PATCH 15/22] W1: add slave_ttl master attribute Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:23 ` [RFC/PATCH 16/22] W1: cleanup masters refcounting & more Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:23 ` [RFC/PATCH 17/22] W1: cleanup slave " Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:25 ` [RFC/PATCH 18/22] W1: cleanup family implementation Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:26 ` [RFC/PATCH 19/22] W1: convert families to be proper sysfs rivers Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:27 ` [RFC/PATCH 20/22] W1: add w1_device_id/MODULE_DEVICE_TABLE for automatic driver loading Dmitry Torokhov
2005-05-19 6:25 ` [RFC/PATCH 20/22] W1: add w1_device_id/MODULE_DEVICE_TABLE for Dmitry Torokhov
2005-04-21 7:36 ` [RFC/PATCH 21/22] W1: implement standard hotplug handler Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 7:38 ` [RFC/PATCH 22/22] W1: expose module parameters in sysfs Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-21 13:18 ` [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-21 14:31 ` Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-25 9:08 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-25 16:32 ` Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-25 19:26 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-25 21:32 ` Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-26 7:19 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-25 20:15 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-25 20:22 ` Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-26 6:43 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-26 6:50 ` Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-26 7:06 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-26 7:16 ` Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-26 7:35 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-26 7:00 ` Greg KH
2005-05-19 6:25 ` Greg KH
2005-04-26 7:17 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-26 6:58 ` Greg KH [this message]
2005-05-19 6:25 ` Greg KH
2005-04-21 16:09 ` Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-25 9:11 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
2005-04-25 16:36 ` Dmitry Torokhov
2005-05-19 6:25 ` Dmitry Torokhov
2005-04-25 19:32 ` Evgeniy Polyakov
2005-05-19 6:25 ` Evgeniy Polyakov
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=20050426065839.GD5889@suse.de \
--to=gregkh@suse.de \
--cc=dtor_core@ameritech.net \
--cc=johnpol@2ka.mipt.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=sensors@stimpy.netroedge.com \
/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.