From: Miles Lane <miles.lane@attbi.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: [Pcmcia-cs-devel]Re: cardmgr and hotplug interplay
Date: Mon, 30 Sep 2002 20:23:07 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-103341745813408@msgid-missing> (raw)
On Mon, 2002-09-30 at 10:15, dhinds wrote:
> On Sat, Sep 28, 2002 at 06:29:57PM -0700, David Brownell wrote:
> >
> > >However, after I been through both the documentation for pcmcia-cs and
> > >for linux-hotplug, I'm still confused about what to expect about them
> > >working together. ...
> >
> > The last time this came up, the expectation was that for 2.4 'cardmgr' would
> > handle the ISA style cards (non-PCI), and hotplugging would handle CardBus
> > ones (standard PCI hotplugging).
>
> That is correct.
>
> > As I recall things, cardmgr is tracking this issue for the (one or two...)
> > PCMCIA drivers it loads. Some of the module changes in 2.5 should IMO
> > include fixes so that driver unload can work reasonably ... it's not
> > quite clear to me what's happening there.
>
> Yes, the PCMCIA subsystem (and cardmgr) keep track of the number of
> devices bound to a driver, so drivers are unloaded when there are no
> longer any bound devices.
>
> > >2) I have all respect for the work that the hotplug developers has put
> > > into the hotplug system. But it appears that cardmgr still
> > > provides a better handling of the cardbus cards (I haven't tried,
> > > but I assume that it would be capable of removing the driver
> > > afterwards). Is there a way letting it not try to handle cardbus
> > > cards?
> >
> > I wouldn't know, but keep in mind that if you go that route you're
> > suddenly in the business of maintaining lots of entries in that
> > /etc/pcmcia/config file that are exactly in sync with all the
> > MODULE_DEVICE_TABLE entries in the PCI drivers ... most of which
> > are part of the kernel distribution, not the pcmcia package. That
> > doesn't sound very much "better"! :)
>
> It also isn't better (won't work) because cardmgr really only knows
> how to manage drivers properly if they use the PCMCIA driver API. It
> will try to load other modules if you tell it to, but when those
> modules don't register themselves as PCMCIA drivers, it gets confused.
Well, where do we go from here?
David Woodhouse offered to spearhead the effort of adding PCMCIA
device support to the /sbin/hotplug system when he got some free
time, but it seems he never had enough free time to make it happen.
My understanding is that the two of you have had some discussion of
the possibilities and that there is some code that David has that
he doesn't feel is ready for general consumption.
Miles
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
reply other threads:[~2002-09-30 20:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=marc-linux-hotplug-103341745813408@msgid-missing \
--to=miles.lane@attbi.com \
--cc=linux-hotplug@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).