From: Adam Belay <abelay@novell.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Patrick Mochel <mochel@digitalimplant.org>,
Greg KH <greg@kroah.com>,
linux-pm@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [linux-pm] Re: [RFC] Driver States
Date: Wed, 06 Apr 2005 15:51:12 -0400 [thread overview]
Message-ID: <1112817072.8517.15.camel@linux.site> (raw)
In-Reply-To: <20050405092423.GA7254@elf.ucw.cz>
On Tue, 2005-04-05 at 11:24 +0200, Pavel Machek wrote:
> Hi!
>
> > > You have a few things here that can easily conflict, and that will be
> > > developed at different paces. I like the direction that it's going, but
> > > how do you intend to do it gradually. I.e. what to do first?
> >
> > I think the first step would be for us to all agree on a design, whether
> > it be this one or another, so we can began planning for long term
> > changes.
> >
> > My arguments for these changes are as follows:
>
> 0. I do not see how to gradually roll this in.
>
> > 4. Having responsibilities at each driver level encourages a
> > layered and object based design, reducing code duplication and
> > complexity.
>
> Unfortunately, you'll be retrofiting this to existing drivers. AFAICS,
> trying to force existing driver to "layered and object based design"
> can only result in mess.
> Pavel
Fair enough. How does this sound? I'd like to add "*attach" and
"*detach" to "struct device_driver". These functions would act as one
time initializers and decontructors. Then we could rename "*probe" to
"*start", and "*remove" to "*stop", which should be rather trivial to
fix up. From there drivers could slowly be converted to use "*attach"
and "*detach", but will not be broken along the way.
So the basic flow would be like this:
1.) a driver is bound to a device
2.) *attach is called to allocate data structures
3.) *start when it's time to probe the device
4.) *stop when the user disables the device
5.) repeat steps 3 and 4 any number of times
6.) *detach is called when unbinding the driver
The driver layering stuff could come later, but just implementing these
specific components would have immediate benefits.
In this early stage in development, I'd like to at least be able to
start and stop drivers for reasons outside of power management (ex. user
preference or resource re-balancing). If a "*resume" function can also
utilize this functionality, then all the better.
Thanks,
Adam
next prev parent reply other threads:[~2005-04-06 19:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-27 22:42 [RFC] Driver States Adam Belay
2005-03-30 5:57 ` Patrick Mochel
2005-03-30 22:45 ` Adam Belay
2005-04-05 9:24 ` [linux-pm] " Pavel Machek
2005-04-06 19:51 ` Adam Belay [this message]
2005-04-08 10:31 ` Pavel Machek
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=1112817072.8517.15.camel@linux.site \
--to=abelay@novell.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=mochel@digitalimplant.org \
--cc=pavel@ucw.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox