[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: interesting times installing 2.4.17 in Woody...

On Fri, Feb 01, 2002 at 12:13:06PM -0500, Brian Mays wrote:
> Strangely enough, your message has excellent timing, since I am
> currently in the building and testing process for the next version
> of the pcmcia packages, which (I hope) will solve this problem.  My
> solution is as follows.  I would appreciate any feedback.

I am the submitter of pcmcia-cs bug 134102.  I was just catching up
on debian-devel and noticed this message, which helps me
tremendously.  May I point out that this explanation would be even
more valuable in the pcmcia-cs package?  I think this scheme is
likely to confuse users, and they are not likely to find this

> This solution requires a couple of hacks to the pcmcia-cs software.
> First, the probe utility is modified to report that the "yenta_socket"
> module should be used for the CardBus chips (ISA-to-PCMCIA bridges
> will still be correctly reported as using "i82365").  This means that
> new installations should correctly have PCIC=yenta_socket set in
> /etc/default/pcmcia.  To handle upgrades from older packages, I have
> added an option during the upgrade (using debconf) to have the postinst
> script automatically fix the PCIC entry in the /etc/default/pcmcia file.
> Of course, the stand-alone drivers (in the pcmcia-modules packages)
> don't have a yenta_socket module.  Therefore, I have added an additional
> file in /etc/default to the pcmcia-modules packages that is sourced (if
> it exists) by /etc/init.d/pcmcia and changes PCIC from "yenta_socket" to
> "i82365", which is appropriate for the stand-alone drivers.

As I mentioned in my bug, there is one (IMO) serious flaw.  Users of
old pcmcia-modules packagse will not have this additional
/etc/default file, so their configs will be broken.  Since many
users compile their own pcmcia-modules, possibly against multiple
kernel variants, and may be reluctant to upgrade known-working
modules, I think this will affect a lot of people.

Here is a counter-proposal:  Instead of modifying /etc/init.d/pcmcia
to source a new file, just make it responsible for mapping
yenta_socket -> i82365 when a compatible pcmcia-modules package is
detected.  If you think that hard-coding that mapping is too ugly,
honor a new value for PCIC, eg cardbus, that -> yenta_socket for
kernel, -> i82365 for stand-alone.

> Next, I have made the appropriate changes to the /etc/pcmcia/config file
> to support the kernel drivers.  An additional workaround was required to
> also support the stand-alone drivers.  Therefore, I modified the cardmgr
> program to support the following construct in its config file:
>     source ./config-`uname -r`.fix

This makes me nervous for the same reason (although AFAICT it
doesn't affect any of my cards).  pcmcia-cs itself should be
responsible for fixing the config for pcmcia-modules versions prior
to this scheme.  Eg, supply /etc/pcmcia/config-old-stand-alone.fix
that is sourced when an old pcmcia-modules is detected.

Or, really, just hard-code the whole deal in pcmcia-cs, and forget
about sourcing version-specific fix-ups.  The stand-alone and kernel
drivers aren't likely to break compatibilty with themselves, right?
So there are only two variants that you'll ever have to worry about,
and hard-coding them should be fine.

Does this make sense?  I would be happy to help work out the
details, because I think this will bite upgraders.


Reply to: