DSA Terminology

I'm hoping some contributors to the mailing list read this part of the forum. I don't think it would be good form for me to attempt to join the developers mailing list.

Re: the current discussion around DSA terminology - some excerpts follow:

Well, it would still be less confusing than the state we're currently in.
Anyway, converting "config interface" to "config network" and "config
device" to "config iface" is an option.

I don't like iface, it is also easily confused with interface (which - as
explained - still has to be supported in the forseeable future even after the

Apart from that we should try to rid of abbreviations in configuration or at
the very least follow a consistent set of rules (if there'd be a config iface then networks should be called option net).

This cannot be done in a sane manner though as it would render future versions
entirely backwards incompatible.

Renaming config interface to config network makes sense and can be
implemented easily. However we would still need to treat config interface as
synonym for it in the forseeable future in order to retain compatibility,
which means that we cannot reuse interface for something else.

So changing config interface to config network would be possible assuming
that config device remains config device (or is renamed to something other
than interface).

At the same time, the wifi-iface section type in /e/c/network should be
changed to wifi-network in order to remain consistent.
The problem: "config interface" (and the similar "wifi-iface"). We're switching
the word "interface" (and "iface") that has been used in config files from one
concept to another. This could leave the config files with ambiguous commands.


I suggest that using the same or similar term to mean different things is a recipe for great confusion.

I suggest that any new terminology is flagged by prefixing the term with 'DSA', so we have:


this is unambiguous, and shows that the new terms are connected to the use of DSA, rather than having to guess what interface and iface really mean.

Configuration files could accept both an old (arguably incorrect) term or the new DSA terminology as synonyms without causing confusion.

If a subsequent revision of DSA terminology occurs, it would be simple enough to flag with DSA2device, DSA2interface, DSA2network etc.

At some point, use of the older terminology could be deprecated and one-off configuration translation/rewriting process applied at a system upgrade, if it were felt important enough.

1 Like

This isn't really related to DSA though, so prefixing with DSA would be a misnomer and confusing. As explained in the thread, DSA is a concept that gives you one linux netdev per switch port. But the very same considerations apply to e.g. a system with a bunch of dedicated NICs and no embedded switch IC at all.

Also do you seriously propose shipping an /etc/config/network with config DSA2interface wan6? I don't think that this will fly.

1 Like

OK, I'm not wedded to using DSA as a prefix, but some other prefix would be fine. The point is to make terms unambiguous, which allows their use as synonyms in configuration files.

As for the contents of /etc/network/config, there is an expectation that configuration files contain technical terms in their contents. Using meaningful symbols can be helpful, or conversely, if you don't want to overload the symbol name, use non-meaningful differentiators, like interface-type-foo and interface-type-bar. It doesn't really matter, so long as people are not led down the path of thinking that interface and iface are the same thing.

Complexity in configuration files is not unknown. Try looking at an fstab where disks are referred to by UUID