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
message.
> 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.
Andrew
Reply to: