xvifX.Y vs sysctl_create() returning 22 (EINVAL)

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Hi list,

Due to the syntax currently used for xvif(4) interfaces, their creation
during a domU start results in the following messages logged:

Jan 10 00:02:26 paris /netbsd: xvif108.0: could not attach sysctl nodes
Jan 10 00:02:57 paris /netbsd: sysctl_createv: sysctl_create(xvif108.0)
returned 22

Consequently, the interface is not visible under net.interfaces in
sysctl(7).

Fixing this issue would need to get rid of the "." from the interface
name, and replace it with a correct char acceptable for the MIB.

Sadly, we cannot make such a "radical" change without breaking current
scripts used for vif initialization, like etc/xen/scripts/vif-ip or
vif-bridge (the pattern is hardcoded within).

I would like to propose the following changes, so to ease the transition
a bit:

- similar to what is done for XenSource's Linux, create a "vifname" node
inside XenStore, which contains the vifnames (doh!) for the domain just
created. In our case, for dom0, that would be "xvifX-Y", or anything
that avoid using dots in the name (X being domU ID and Y the frontend
interface ID).

- modify the vif-ip and vif-bridge scripts: introduce a
"xenstore_read_default" function, like done for Linux:

# xenstore_read_default <path> <default>
#
# Read the given path, returning the value there or the given default
# if the path is not present.
#
xenstore_read_default() {
  xenstore-read "$1" 2>/dev/null || echo "$2"
}

- use it to query the "vifname" keys; obviously, keep the "xvifX.Y" as
default syntax.

- wait for an arbitrary amount of time (TBD), so that Xen scripts get
eventually replaced by their newer versions.

- finally, modify the syntax in kernel. Consequence: vifname will change
its syntax within xenstore for each new domU, and the newer scripts will
take that into account "automagically."

Opinions?

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost