DSA Terminology

Val Kulkov val.kulkov at gmail.com
Tue Sep 13 19:38:32 PDT 2022


Hi Rich,

On Tue, 13 Sept 2022 at 21:42, Rich Brown <richb.hanover at gmail.com> wrote:
>
> Let me rephrase to be sure if I understand correctly:
>
> > On Sep 13, 2022, at 3:56 PM, Jo-Philipp Wich <jo at mein.io> wrote:
> >
> >
> > 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.
>
> I am assuming that the code that processes /etc/config/network and /etc/config/wireless is the difficulty. It would be possible to change names on labels in the GUI, and to update the documentation with the new terms. But we need to be able to handle existing configuration files - either to accept them, convert them, or give cogent error messages.
>
> That code could retain the current "config device..." to refer to things that move bits (that is, things we have defined as "interfaces" in this current discussion) No change to uci processing would be necessary.
>
> That code could use "config network" as a new synonym for things that were formerly "interfaces". uci would need to treat "network" in the same way as it formerly handled "interface"
>
> That code could treat "config wifi-network" as a new synonym for "config wifi-iface" (for parallelism with the new "network").
>
> 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.
>
> How could the code that reads those configuration files handle the presence of "interface/iface" keywords? Thanks.

My understanding of jow's proposal is that in order to avoid breaking
backward compatibility, we can do this:

"config interface" becomes "config network" in /e/c/n
"config interface" in /e/c/n/ becomes obsolete and not recommended for
future use, but for backward compatibility "config interface" would
still be a synonym of "config network" for now
"config wifi-iface" becomes "config wifi-network" in /e/c/w
"config wifi-face" in /e/c/w becomes obsolete and not recommended for
future use, but for backward compatibility "config wifi-iface" would
still be a synonym of "config wifi-network" for now

"config device" and "option device" would retain their current meaning, for now.



More information about the openwrt-devel mailing list