Re: tun device - bug or feature? WAS(Re: IMQ / new Dummy device post.

[Max Krasnyansky <maxk@qualcomm.com>]

On Sat, 2004-05-08 at 04:55, jamal wrote:
> Max, Dave, Jeff,
> 
> I get what was bothering me now - it took me a while to formulate it:
> 
> TUN_TUN_DEV dev->type is ARPHRD_PPP
> dev->type is really related to link layer header, perhaps at the low
> level if neighbor discovery works well then we have a link-headerless
> packet which gets manipulated with the correct header by some generic
> code. The combination of dev->type and dev->hard_header_len works
> together to achieve this.
> In the case of TUN_TUN_DEV, the header_len is 0 ;->
> To be of type ARPHRD_PPP, tun needs to have a header_len which is the
> size of the l2 ppp header.
> As an example, TUN_TAP_DEV is fine as type ARPHRD_ETHER and header_len
> of ETH_HLEN.
> 
> A lot of devices are abusing this system, tun is not the only one.
> 
> My suggestion is to change dev->type to ARPHRD_VOID for TUN_TUN_DEV or
> we introduce something like ARPHDR_NONE for devices with link layer
> headers of size 0.
> 
> thoughts?

I have no problem with that. I mean introducing new ARPHDR_ type.
ARPHDR_PPP was simply most appropriate for TUN that's why I picked it.
I vote for ARPHDR_NONE.

Thanks
Max