> > - cpc_init() is the function that detects the boards and initializes the
> > network devices (cpc0, cpc1, etc.);
> > - cpc_probe returns -1 so that the invalid and useless device "cpc" is
> > removed from the device chain.
>
> Yeah. The kernel is still walking the list building the driver table at
> this point, so shit could happen. You probably will need to preallocate
> them in 2.2.x - ick
The problem is that this will raise another issue (which I've mentioned
before) ...
If I preallocate the device structures in Space.c, I will _have to_ use
them. However, in the interface with syncppp, the structure ppp_device
contains a 'struct device' structure (not a pointer), which is the device
structure used in every driver that uses syncppp.
The problem is that as this is not a pointer, it can't be the same
structure as the one defined in Space.c (or can it??) and, thus, I don't
have how to tell the driver (and syncppp) to use the structure defined in
Space.c. If I use the Space.c definition in the driver, it will not be in
sync with the ppp_device structure, and that will surely cause problems.
Shouldn't pppdev.dev be a pointer to a 'struct device' structure?? How can
I solve this problem???
I think this problem wasn't spotted before because all the other WAN card
drivers currently available are only "compileable" as modules.
To make things worse, imagine the case where the driver supports several
different protocols (which actually is the case of my driver -- it
supports X.25 as well as PPP/Cisco HDLC). In this case, I would have to
declare the ppp_device structure anyway just to use the struct device
inside it, and this doesn't sound right to me. Do you agree??
Please let me know your thoughts about this.
Regards,
Ivan
-
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/