| To: | hadi@xxxxxxxxxx |
|---|---|
| Subject: | Re: RFC: PPP over X |
| From: | Henner Eisen <eis@xxxxxxxxxxxxx> |
| Date: | Thu, 10 Feb 2000 00:33:54 +0100 |
| Cc: | mostrows@xxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, axboe@xxxxxxx, markster@xxxxxxxxx, mitch@xxxxxxxxxx, ak@xxxxxxx, marc@xxxxxxx, paulus@xxxxxxxxxxxxx, bcrl@xxxxxxxxxx |
| In-reply-to: | <Pine.GSO.4.20.0002081750300.7200-100000@shell.cyberus.ca> (message from jamal on Tue, 8 Feb 2000 17:53:15 -0500 (EST)) |
| References: | <Pine.GSO.4.20.0002081750300.7200-100000@shell.cyberus.ca> |
| Sender: | owner-netdev@xxxxxxxxxxx |
Yet another idea: Why not generalizing (essentially, it is just renaming) the paradigm 'attaching ppp channel to connected socket' to 'attaching/tunneling arbitray protocol over connected socket' ? The channel API, although there is 'ppp' in the name prefixes, is very generic and not exclusivly useful to ppp_generic.c. It would be possible to write software net_device drivers (e.g. one for each encapsulation protocol) which communicate the downstream data by means of the channel API. (The only difference seems that the channel is not registered for ppp but somewehere else). Then, as the generic socket code will use the ppp_channel API anyway, attaching the socket to a real ppp channel will not be any different from attaching it to some other software net_device driver. We Henner |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: RFC: PPP over X, Henner Eisen |
|---|---|
| Next by Date: | Re: RFC: PPP over X, Paul Mackerras |
| Previous by Thread: | Re: RFC: PPP over X, Henner Eisen |
| Next by Thread: | Re: RFC: PPP over X, Paul Mackerras |
| Indexes: | [Date] [Thread] [Top] [All Lists] |