The subject says it all. Is there any particular (technical) reason why I
must have both the generic pcmcia code and the controller support
built-in, or build all of them as modules?
/Tobias
On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote:
> The subject says it all. Is there any particular (technical) reason why I
> must have both the generic pcmcia code and the controller support
> built-in, or build all of them as modules?
Is there a technical reason for this? Not that I know of; but then I
also cannot think of a good reason for wanting, say, the generic code
built in but the controller support as modules. I do see reasonable
arguments for all-builtin or all-modules.
-- Dave
>> The subject says it all. Is there any particular (technical) reason
>> why I must have both the generic pcmcia code and the controller
>> support built-in, or build all of them as modules?
>
> Is there a technical reason for this? Not that I know of; but then I
> also cannot think of a good reason for wanting, say, the generic code
> built in but the controller support as modules. I do see reasonable
> arguments for all-builtin or all-modules.
Hmmm, I'm not the only one who doesn't like modules depending
on other modules. I suppose this is part paranoia about extra
complexity leading to problems, and part desire to avoid the
module overhead for common code that will most likely get used.
On Tue, Nov 21, 2000 at 08:10:38PM -0500, Albert D. Cahalan wrote:
>
> Hmmm, I'm not the only one who doesn't like modules depending
> on other modules. I suppose this is part paranoia about extra
> complexity leading to problems, and part desire to avoid the
> module overhead for common code that will most likely get used.
Since the core PCMCIA code and the socket driver are equally essential
to do anything useful with PCMCIA, the only reasonable argument I
could see for it would be if you are using one kernel on several
systems, all of which use PCMCIA, but which need different socket
drivers. So you would save... oh... perhaps 2K by having the PCMCIA
shared code in the kernel.
In any case, I don't think it would require much more than modifying
the Config.in for the PCMCIA drivers to support this. My own paranoia
would be that you would be adding a bunch of rarely used permutations
of config options, that would rarely be tested.
-- Dave
David Hinds <[email protected]> said:
[...]
> Is there a technical reason for this? Not that I know of; but then I
> also cannot think of a good reason for wanting, say, the generic code
> built in but the controller support as modules. I do see reasonable
> arguments for all-builtin or all-modules.
If you have a laptop with an assortment of cards, you might want to have
the generic builtin and the cards themselves as modules.
Pretty weak, I know.
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
On Tue, Nov 21, 2000 at 10:44:30PM -0300, Horst von Brand wrote:
>
> If you have a laptop with an assortment of cards, you might want to have
> the generic builtin and the cards themselves as modules.
No, that's ok, and that's supported with the current config scripts.
The original question was about having the generic code built in, but
the socket driver (yenta) as a module. The socket driver needs to be
loaded regardless of what cards you're using. So I think having one
in the kernel and the other as a module is of limited utility.
-- Dave
On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote:
> The subject says it all. Is there any particular (technical) reason
> why I must have both the generic pcmcia code and the controller support
> built-in, or build all of them as modules?
>
> /Tobias
Wasn't there some strange laptop model which had PCMCIA floppy/CDROM,
which are unavailable to bootstrap process, unless PCMCIA is supported
at the booting kernel ?
Or was it about USB floppy at some other laptop?
On Tue, 21 Nov 2000, David Hinds wrote:
> On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote:
> > The subject says it all. Is there any particular (technical) reason why I
> > must have both the generic pcmcia code and the controller support
> > built-in, or build all of them as modules?
>
> Is there a technical reason for this? Not that I know of; but then I
> also cannot think of a good reason for wanting, say, the generic code
> built in but the controller support as modules. I do see reasonable
> arguments for all-builtin or all-modules.
Maybe more a matter of taste, or real life problems. I wanted a kernel
with yenta and i82365 built-in, but I need to specify extra_sockes to the
i82365. There is no way to do this unless it is a module. Then I thought,
why not have yenta build-in, and i82365 as a module, and discovered that
that was not possible. I know, I should add a __setup thingie to i82365,
but...
As for taste, the generic pcmcia code is not a driver, and it would make
sense to me to have that support in the kernel, not in a module.
/Tobias
[email protected] said:
> Is there a technical reason for this? Not that I know of; but then I
> also cannot think of a good reason for wanting, say, the generic code
> built in but the controller support as modules. I do see reasonable
> arguments for all-builtin or all-modules.
register_ss_entry() is broken and when you unload a socket driver it'll get
very confused and leave /proc entries behind. You can clean this up by
removing pcmcia_core.o and reloading it.
If you have pcmcia_core.o built in and a socket driver as a module, then
obviously you can't do this without rebooting.
I doubt this was known at the time the Config.in choices were made, but
it's sufficient reason right now to leave it as it is.
The correct fix is to dump the static socket tables completely, as has
already happened in the standalone code, but I think that should probably
wait for 2.5. In the meantime, this patch ought to work around the problem
for most cases - although it'll still break if you load 2 socket drivers,
then unload them again FIFO.
Index: drivers/pcmcia/cs.c
===================================================================
RCS file: /net/passion/inst/cvs/linux/drivers/pcmcia/Attic/cs.c,v
retrieving revision 1.1.2.28
diff -u -r1.1.2.28 cs.c
--- drivers/pcmcia/cs.c 2000/11/10 14:56:32 1.1.2.28
+++ drivers/pcmcia/cs.c 2000/11/22 10:37:33
@@ -416,12 +416,10 @@
{
int i;
- for (i = 0; i < sockets; i++) {
+ for (i = sockets-1; i >= 0; i-- ) {
socket_info_t *socket = socket_table[i];
if (socket->ss_entry == ss_entry)
- pcmcia_unregister_socket (socket);
- else
- i++;
+ pcmcia_unregister_socket (socket);
}
} /* unregister_ss_entry */
--
dwmw2
> Wasn't there some strange laptop model which had PCMCIA floppy/CDROM,
> which are unavailable to bootstrap process, unless PCMCIA is supported
> at the booting kernel ?
I have seen a couple where the floppy/cdrom are supported by the bios but
then vanish. Generally they are left mapped which means if you know the
right ide= incantation it works.
Remember you can solve this with an initrd.
Alan
On Wed, 22 Nov 2000, Matti Aarnio wrote:
> On Tue, Nov 21, 2000 at 11:34:45PM +0100, Tobias Ringstrom wrote:
> > The subject says it all. Is there any particular (technical) reason
> > why I must have both the generic pcmcia code and the controller support
> > built-in, or build all of them as modules?
> >
> > /Tobias
>
> Wasn't there some strange laptop model which had PCMCIA floppy/CDROM,
> which are unavailable to bootstrap process, unless PCMCIA is supported
> at the booting kernel ?
>
> Or was it about USB floppy at some other laptop?
Yes and yes. However, you still would need the controller specific code
built-in.
The USB floppy situation is uglier still. When I tried to put Debian on my
VAIO from floppy, I discovered that even with a USB-enabled kernel, the
floppy wasn't available in time to mount /.
Approaches that did work, in case anyone is curious, were using loadlin
with FreeDOS (incredibly slow) to preload the second floppy via BIOS, or
using syslinux and a custom mini-kernel and initrd image crammed onto a
single floppy.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."