Dirk Koopman wrote:

> Is that actually true? I know that it is generally received wisdom, but if
> the device drivers handled the level 1 issues (including txd, txtail etc) and
> stopped there, would it _actually_ be necessary to have the rest in the
> kernel.

I was using "belongs" in the sense of ownership in the Linux
implementation, not in the more general sense of where these things
should be.

> It seems to me that the only reason that ax25 is there is largely because
> some people want seamless IP integration. Which is a point of view, but not
> necessarily one I would wholeheartedly agree with.

I don't believe that is why it is there. I think it is there in the name
of consistency with, not integration with, the TCP/IP implementation. It
just follows the same model.

> I suppose my main beef with kernel integration is that it makes it very
> difficult if you want to do something which starts to move away from ax25 in a
> controlled fashion, either for experimentation or simply because you want to
> find a better way.

> I, personally, believe that the kernel should handle level 1 issues and
> everything else should be done in user space a la BPQ or Flexnet. This gives
> far more flexibility and would allow (and is likely to encourage) more
> people to fiddle and therefore, maybe, contribute.

I personally don't see how it makes any difference where it belongs.
It's no more of less difficult either way. You have the same issues to
deal with no matter what level. A kernel module is no more of less
difficult to work with than any other arbitrary API you'd need to do the
job. Perhaps it's marginally more difficult to debug.

Van-Jacobsen has argued the TCP rightfully belongs in userspace, which
directly opposes conventional wisdom. He does this though on performance
grounds, not on relative ease of implementation.

Feel free to reimplement it according to your vision. If enough people
think it's better that way perhaps that's how it will be in future.

I was just answering a question.

Terry

Reply via email to