On Thu, 3 Feb 2000, Michal Ostrowski wrote:
> jamal writes:
> > mitch >> -Creating a whole socket family for just PPPOE is a bad idea
> > mitch >
> > mitch >I don't think so - it has its own addressing, so it needs
> > mitch >its own address family.
> > mitch >
> >
> > Bad reason.
> >
>
> What's the difference between adding a new socket family and adding a
> new tty-device type? Yes, a tty-device will probably require less
> infrastructure code (since sockets have a richer interface to
> support). Aside from lines of code what's the difference?
>
>From a semantical point of view there is *none*.
If i was managing the code, i would say it would be easier to manage
something that is smaller (especially when it is more than half the size).
And the rate at which Linux kernel code is growing, it safer to give
a lot of merit to code that provides less bloat to the kernel especially
if they provide the same functionality.
Now if you look at the tty code, you'll see there is still a lot of
unnecesary crap that is not really being used, but is there because the
tty interface needs it.
I dont like that either. Again it seems there is a consensus that maybe
tty is not the way to go.,
>
> >
> > And what about PPP-over-Frame, PPP over UDP ;->
> > Create a new socket family for each?
>
> Just off-the top of my head, you may be able to support PPP over UDP
> simply by adding the appropriate ioctls into the UDP socket code.
>
You will still have to register callbacks for the encap/decap
Which the general population using UDP sockets might not be very excited
about. And if you do add the callbacks then it doesnt make much of a
difference in the end performancewise if you use a generic socket_pppox
interface to do it instead and pipe the data to an open udp socket.
> You may have a good point about PPPoATM --- there may be
enough > similarities between PPPoE and PPPoATM to justify code
> sharing. (Though I'm just speculating here because I haven't had a
> chance to go through the code thoroughly yet.)
I just browsed through it myself.
>
>
> >
> > You need to have both a connect and disconnect; It could be via plugins
> > or the already provided features of "connect" or "disconnect"
> >
>
> Perhaps the existing "connect"/"disconnect" options should be
> integrated into the plugin/hook mechanism. (That is, recognizing one
> of these options registers an appropriate hook.) One may be able to
> do all of the options parsing upon starting up pppd , use the options
> to set hooks and then just rely on the hooks instead of checking
> whether or not a given option is set.
>
Good point. We might have to revisit it later again once the kernel level
issue is settled.
>
> (It's amazing just how little one can accomplish in an afternoon when
> there's e-mail to read/write.)
hehe. Same here. Havent heard from Mark Spencer or Paul Mackerras. It
would be nice to hear from them.
cheers,
jamal
|