From: gregkh@suse.de (Greg KH)
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: dtor_core@ameritech.net, 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: <20050426070003.GE5889@suse.de> (raw)
In-Reply-To: <1114497816.8527.66.camel@uganda>
On Tue, Apr 26, 2005 at 10:43:36AM +0400, Evgeniy Polyakov wrote:
> On Mon, 2005-04-25 at 15:22 -0500, Dmitry Torokhov wrote:
> > On 4/25/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > While thinking about locking schema
> > > with respect to sysfs files I recalled,
> > > why I implemented such a logic -
> > > now one can _always_ remove _any_ module
> > > [corresponding object is removed from accessible
> > > pathes and waits untill all exsting users are gone],
> > > which is very good - I really like it in networking model,
> > > while with whole device driver model
> > > if we will read device's file very quickly
> > > in several threads we may end up not unloading it at all.
> >
> > I am sorrry, that is complete bull*. sysfs also allows removing
> > modules at an arbitrary time (and usually without annoying "waiting
> > for refcount" at that)... You just seem to not understand how driver
> > code works, thus the need of inventing your own schema.
>
> Ok, let's try again - now with explanation,
> since it looks like you did not even try to understand what I said.
> If you will remove objects from ->remove() callback
> you may end up with rmmod being stuck.
Yes, and that is acceptable. networking implemented their own locking
method to allow unloading of their drivers in such a manner. No other
subsystem is going to do that kind of implementation, so Dmitry is
correct here.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@suse.de>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: dtor_core@ameritech.net, sensors@stimpy.netroedge.com,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/PATCH 0/22] W1: sysfs, lifetime and other fixes
Date: Tue, 26 Apr 2005 00:00:03 -0700 [thread overview]
Message-ID: <20050426070003.GE5889@suse.de> (raw)
In-Reply-To: <1114497816.8527.66.camel@uganda>
On Tue, Apr 26, 2005 at 10:43:36AM +0400, Evgeniy Polyakov wrote:
> On Mon, 2005-04-25 at 15:22 -0500, Dmitry Torokhov wrote:
> > On 4/25/05, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > > While thinking about locking schema
> > > with respect to sysfs files I recalled,
> > > why I implemented such a logic -
> > > now one can _always_ remove _any_ module
> > > [corresponding object is removed from accessible
> > > pathes and waits untill all exsting users are gone],
> > > which is very good - I really like it in networking model,
> > > while with whole device driver model
> > > if we will read device's file very quickly
> > > in several threads we may end up not unloading it at all.
> >
> > I am sorrry, that is complete bull*. sysfs also allows removing
> > modules at an arbitrary time (and usually without annoying "waiting
> > for refcount" at that)... You just seem to not understand how driver
> > code works, thus the need of inventing your own schema.
>
> Ok, let's try again - now with explanation,
> since it looks like you did not even try to understand what I said.
> If you will remove objects from ->remove() callback
> you may end up with rmmod being stuck.
Yes, and that is acceptable. networking implemented their own locking
method to allow unloading of their drivers in such a manner. No other
subsystem is going to do that kind of implementation, so Dmitry is
correct here.
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 [this message]
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
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=20050426070003.GE5889@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.