Messages in this thread |  | | | Subject | Re: 2.3.43 breaks pppd! (SOLVED, possible config gotcha) | | Date | Mon, 14 Feb 2000 18:16:24 -0500 | | From | Paul Barton-Davis <> |
| |
>Why? That just doesn't make sense. Why should I have KMOD turned on to >eg. use a joystick? I know, it can make some things easier, but that's a >matter of personal preference. If I don't want KMOD, I just insmod >joystick.o, and it will get char major 15, because it requests it. Why >it should need KMOD?
Two scenarios:
1) a joystick using application calls:
open ("/dev/joystick", ....) (or whatever the canonical name for the joystick is). if you don't have kmod and have not insmod-ed the relevant module, the open(2) call will return with "device not configured" or "no such device".
2) if a driver itself tries to open other devices in the same way, expecting them to be there either via direct compilation or insmod, then it won't work without tricky manual intervention.
In the case of pppd, I think that it was trying to open /dev/ppp, and then later was doing stuff that assumed the existence of the compression modules. even though i had them compiled and "in place", they were not insmod'ed without manual intervention. thus, pppd will not run correctly in this scenario without a user having to figure out all the modules that might be needed. yuck (and in the general case, non-trivial to do).
note, for example, that ppp_generic and ppp_async do *not* depend on the compression modules, but that pppd (and perhaps the ppp driver too, not sure about that) requires them. so depmod doesn't help here either.
--p
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |