IFNAMSIZ/IF_NAMESIZE change proposal

[Anuranjan Shukla]

Hi,
At Juniper Networks, interface name size was needed to be longer than what FreeBSD has. We're trying to reduce our local changes to FreeBSD to allow us an easier time upgrading to newer FreeBSD releases, and support the modularization of the network stack we'd proposed earlier. I'm sending this out to propose changing IFNAMSIZ from 16 to 60 (this is the size we use) in FreeBSD. We don't see any downside (other than increasing the ifreq structure size for one) to doing this, as allowing longer interface names can be handy for vendors. I'd like to hear if there's a strong objection to this. If not, we'd like to get this into to the FreeBSD codebase. Any thoughts/objections highly appreciated.

Thanks,
Anu

[Warner Losh]

Post by Anuranjan Shukla
At Juniper Networks, interface name size was needed to be longer than what FreeBSD has. We're trying to reduce our local changes to FreeBSD to allow us an easier time upgrading to newer FreeBSD releases, and support the modularization of the network stack we'd proposed earlier. I'm sending this out to propose changing IFNAMSIZ from 16 to 60 (this is the size we use) in FreeBSD. We don't see any downside (other than increasing the ifreq structure size for one) to doing this, as allowing longer interface names can be handy for vendors. I'd like to hear if there's a strong objection to this. If not, we'd like to get this into to the FreeBSD codebase. Any thoughts/objections highly appreciated.

56 or 64 would be better for alignment, wouldn't it?

Warner

[Marcel Moolenaar]

Post by Warner Losh

Post by Anuranjan Shukla
At Juniper Networks, interface name size was needed to be longer than
what FreeBSD has. We're trying to reduce our local changes to FreeBSD to
allow us an easier time upgrading to newer FreeBSD releases, and support
the modularization of the network stack we'd proposed earlier. I'm
sending this out to propose changing IFNAMSIZ from 16 to 60 (this is
the size we use) in FreeBSD. We don't see any downside (other than
increasing the ifreq structure size for one) to doing this, as allowing
longer interface names can be handy for vendors. I'd like to hear if
there's a strong objection to this. If not, we'd like to get this into
to the FreeBSD codebase. Any thoughts/objections highly appreciated.

56 or 64 would be better for alignment, wouldn't it?

Yes, but then we need to change Junos' definition to
match FreeBSD's and we're not sure yet if that's at
all possible. Hence the suggestion to use what we have
at Juniper. If a "nicer" length is preferred, then
we'll see about making that happen.

Thoughts?

[Julian Elischer]

Post by Warner Losh

Post by Anuranjan Shukla
At Juniper Networks, interface name size was needed to be longer than what FreeBSD has. We're trying to reduce our local changes to FreeBSD to allow us an easier time upgrading to newer FreeBSD releases, and support the modularization of the network stack we'd proposed earlier. I'm sending this out to propose changing IFNAMSIZ from 16 to 60 (this is the size we use) in FreeBSD. We don't see any downside (other than increasing the ifreq structure size for one) to doing this, as allowing longer interface names can be handy for vendors. I'd like to hear if there's a strong objection to this. If not, we'd like to get this into to the FreeBSD codebase. Any thoughts/objections highly appreciated.

Divert already has a problem with 16, since it tries (or fails if > 8
) to pack the interface name into the 'unused'
bytes of a sockaddr.
60 just makes things worse, but since it already fails at 16 I can't
really object.
but it would be nice if we could think of a better mechanism for
divert reinjection.

Post by Warner Losh
56 or 64 would be better for alignment, wouldn't it?
Warner
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-net

[Julian Elischer]

Post by Julian Elischer

Post by Warner Losh

Post by Anuranjan Shukla
At Juniper Networks, interface name size was needed to be longer
than what FreeBSD has. We're trying to reduce our local changes to
FreeBSD to allow us an easier time upgrading to newer FreeBSD
releases, and support the modularization of the network stack we'd
proposed earlier. I'm sending this out to propose changing
IFNAMSIZ from 16 to 60 (this is the size we use) in FreeBSD. We
don't see any downside (other than increasing the ifreq structure
size for one) to doing this, as allowing longer interface names
can be handy for vendors. I'd like to hear if there's a strong
objection to this. If not, we'd like to get this into to the
FreeBSD codebase. Any thoughts/objections highly appreciated.

Divert already has a problem with 16, since it tries (or fails if >
8 ) to pack the interface name into the 'unused'
bytes of a sockaddr.
60 just makes things worse, but since it already fails at 16 I can't
really object.
but it would be nice if we could think of a better mechanism for
divert reinjection.

having said that I guess divert could just define a different
sockaddr_divert
to use instead, sinc eit is a different family.

Post by Julian Elischer

Post by Warner Losh
56 or 64 would be better for alignment, wouldn't it?
Warner
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-net

_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Alexander V. Chernikov]

Post by Anuranjan Shukla
Hi,
At Juniper Networks, interface name size was needed to be longer than what FreeBSD has. We're trying to reduce our local changes to FreeBSD to allow us an easier time upgrading to newer FreeBSD releases, and support the modularization of the network stack we'd proposed earlier. I'm sending this out to propose changing IFNAMSIZ from 16 to 60 (this is the size we use) in FreeBSD. We don't see any downside (other than increasing the ifreq structure size for one) to doing this, as allowing longer interface names can be handy for vendors. I'd like to hear if there's a strong objection to this. If not, we'd like to get this into to the FreeBSD codebase. Any thoughts/objections highly appreciated.

Changing this will break route socket (if_announcemsghdr).
We definitely need some rtsock changes in many areas so maybe we can
consider bumping rtsock version for 10.0, however it needs to be
discussed (maybe at Malta?)

Post by Anuranjan Shukla
Thanks,
Anu
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-net