> > There's still a small problem with loading lp as a module in this way, in
> > that if you are using kerneld to load parport for you, you'll get parport0
> > the first time but parport1 after parport0 goes away.
> That's what you call a 'small problem'? Joe user uses kerneld, does not
> specify parameters and his printer works once, then mysteriously quits.
If you need that lp doesn't install itself on a particular port, you can
compile parport and parport_lowlevel into the kernel (not as modules) and
there are boot parameters to get parport[n] bound to a known address.
Something like the patch below might fix the problem with modules. The
reason for the CONFIG_PARPORT_OTHER conditional is that, if portcount were
decremented regardless every time a parport got unregistered, things like
"insmod parport_pc; insmod parport_ax; rmmod parport_pc; insmod
parport_pc" would fail (the actual count of ports would still be accurate,
but portcount is used as a pointer to the next number to be used). You
can't go shuffling around existing registered parports to make up for the
discrepancy either.
I think that there's a reason for not looking for "gaps" when registering
a port, too (register parport0, register parport1, unregister parport0,
then re-register at parport*0* rather than parport2). I can't think what
it is at the moment.
Comments welcome.
Tim.
*/
--- linux/drivers/misc/parport_share.c~ Sun Feb 8 20:44:11 1998
+++ linux/drivers/misc/parport_share.c Sun Feb 8 20:44:13 1998
@@ -131,6 +131,11 @@
}
}
kfree(port);
+
+#ifndef CONFIG_PARPORT_OTHER
+ /* All ports will be registered/unregistered in one go */
+ portcount--;
+#endif
}
void parport_quiesce(struct parport *port)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu