Re: Bug#147077: What is with the kernel maintainer? (How not to close Bug#147077)
reopen 147077
thanks
Herbert Xu wrote:
> > > ... how about those who are using home made pcmcia-cs tools that
> > > still rely on the symlink?
Brian Mays wrote:
> > Pcmcia-cs tools that old use insmod and thus are broken anyway for
> > the pcmcia drivers in the current 2.4 series kernels. I'm sure
> > you'll agree with me here; you complain about pcmcia-cs using insmod
> > all the time.
Herbert Xu wrote:
> That's true only if they use yenta and did not include isa-pnp through
> other means.
Only for yenta? Not really. Please look again at Bug#144613, which you
reassigned to pcmcia-cs. The following problem was cited in this
report:
:> After upgrading to the latest versions in woody of
:> kernel-pcmcia-modules-2.4.18-686 and kernel-image-2.4.18-686, I get
:> the following errors from /etc/init.d/pcmcia start:
:>
:> Starting PCMCIA services: modules
:> /lib/modules/2.4.18-686/pcmcia/i82365.o: unresolved symbol isapnp_find_dev_R9991be23
:> /lib/modules/2.4.18-686/pcmcia/ds.o: init_module: Operation not permitted
:> Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
:> cardmgr.
To which, you added:
: This is a bug in pcmcia-cs since it's using insmod rather modprobe to
: load i82365.o.
The problem is not only with "yenta", it is with other drivers as well.
I'll admit that this problem wouldn't occur if the user took care to
ensure that isa-pnp is loaded through other means before hand, but that
is a weak argument. The user could just as easily modify
/etc/init.d/pcmcia to use modprobe instead of insmod. Thus, the
compatibility symlinks are not necessary.
Please stop trying to argue that these links still exist for a valid
purpose.
> For starters removing the symlink doesn't really solve the problem
> that got you here. Sure it will stop the errors in dpkg. But it
> doesn't solve the fundamental problem of including two sets of modules
> with identical names under the same directory.
By this, I assume you mean under the same directory tree, e.g.,
/lib/modules/2.4.18/.
Why exactly is this a problem? As far as I know, this doesn't actually
break anything. (If it does, please provide a specific example of
something breaking rather than making general statements.) That is,
nothing is actually broken by having two files with the same name under
one of these directory trees. Modprobe will load the first driver it
finds, and it always searches in a well-defined way. Thus, the kernel
driver will always be preferred by modprobe over the stand-alone driver
with the same name, because the kernel driver is located under the
"kernel" subdirectory.
I could easily support having both sets of drivers installed for one
kernel by slightly modifying the pcmcia system (cardmgr et al.) to
always use "insmod" with the stand-alone drivers (the old way of doing
things) and always use "modprobe" with the kernel drivers. The
compatibility symlinks would definitely need to be removed for this to
work, however.
> Using conflicts would solve this problem but as you are aware it is
> not trivial to implement cleanly.
Indeed. Getting the pcmcia packages to cooperate with the kernel
packages has not been trivial to implement cleanly.
> IMHO this is a documentation issue: the user needs to be aware that
> they should choose one set of PCMCIA modules rather than having both.
This is now obvious with the latest set of Debian pcmcia packages, which
conflict with each other. The major source of confusion that remains is
the kernel configuration help entry for CONFIG_PCMCIA:
:: CONFIG_PCMCIA
:: Say Y here if you want to attach PCMCIA- or PC-cards to your Linux
:: computer. ...
This entry does not mention the stand-alone drivers at all and leaves
the impression that turning this option on is absolutely necessary for
PCMCIA support, which is not true. As a result, individuals who have
been using PCMCIA and Debian for years select this option and then
proceed as they have always done, building and installing the
stand-alone modules (say in a custom pcmcia-modules package), not
realizing that they have built two sets of PCMCIA modules.
The first step for fixing the documentation should be to fix this entry
to better reflect the current state of PCMCIA support under Linux.
> Alternatively kernel-package could be modified to always put PCMCIA
> modules in a separate package.
This would go a long way to clarifying things, since it would become
obvious that a set of PCMCIA drivers has been built from the kernel
sources. (This is not at all obvious now, with the modules buried deep
in the kernel-image package.) I assumed that any scheme to do conflicts
the right way would probably require modifications to make-kpkg to place
the PCMCIA modules in a separate package. I am happy to leave the
details to you an Manoj, however.
The ideal case would be for make-kpkg to check for PCMCIA support in the
kernel and
(1) if PCMCIA support has been built as modules, split the PCMCIA
drivers into a separate package that conflicts with the
corresponding pcmcia-modules package, or
(2) if PCMCIA support has been compiled into the kernel itself (instead
of as a module) leave the other PCMCIA drivers in the kernel-image
package, which should conflict with the corresponding pcmcia-modules
package.
Anyway, it appears to me that there is enough that needs to be done to
warrant reopening this bug report. If you and Manoj want to fix
make-kpkg to add the proper conflicts to the kernel packages, then
reassign this bug to kernel-package. As I have indicated above, I would
still like to see the symlinks in the pcmcia subdirectory removed,
however.
- Brian
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: