Is your feature request related to a problem? Please describe.
Currently, /kernel/patches/90-netkit_support.patch is used to patch the kernel into generating a constant MAC address for a network interface by computing the SHA-1 hash of the hostname and interface name. If the user desires a random MAC address (which is the standard functionality but noticeably slower), they must recompile the kernel with the CONFIG_UML_NET_RANDOM_MAC configuration option.
The user must be given this option without having to recompile the kernel, and potentially be able to specify a constant MAC address too.
Describe the solution you'd like
vstart's --ethN=DOMAIN option should be able to specify a MAC address too, such as --ethN=[HW_ADDR],DOMAIN. This must be optional. To avoid conflict with TAP specifications (which also use comma delimiters) the code must be able to distinguish between the two; this should be doable without breaking backwards compatibility since TAP specifications use two commas.
Passing the address to the kernel is done as the following (i.e., utilising the second parameter):
ethN=daemon,<mac-address>,,/path/to/socket
This should be an option for vconf too.
If the user desires, they should be able to specify random MAC addresses with --random-mac (or similarly named option). This will apply to all interfaces that lack a provided address. Because this function cannot trigger the relevant code in the kernel, the host machine will instead generate the MAC address in vstart and pass it to the kernel command line as is the case with a user-provided address. This will be quicker than the UML kernel's random generator.
Describe alternatives you've considered
Keep the patch. This is not an ideal solution since the user may not be aware of the patch (instead assuming a standard UML kernel) and the patch will require constant updating in-line with kernel development to prevent breaking.
Is your feature request related to a problem? Please describe. Currently, /kernel/patches/90-netkit_support.patch is used to patch the kernel into generating a constant MAC address for a network interface by computing the SHA-1 hash of the hostname and interface name. If the user desires a random MAC address (which is the standard functionality but noticeably slower), they must recompile the kernel with the
CONFIG_UML_NET_RANDOM_MACconfiguration option.The user must be given this option without having to recompile the kernel, and potentially be able to specify a constant MAC address too.
Describe the solution you'd like vstart's
--ethN=DOMAINoption should be able to specify a MAC address too, such as--ethN=[HW_ADDR],DOMAIN. This must be optional. To avoid conflict with TAP specifications (which also use comma delimiters) the code must be able to distinguish between the two; this should be doable without breaking backwards compatibility since TAP specifications use two commas.Passing the address to the kernel is done as the following (i.e., utilising the second parameter):
This should be an option for vconf too.
If the user desires, they should be able to specify random MAC addresses with
--random-mac(or similarly named option). This will apply to all interfaces that lack a provided address. Because this function cannot trigger the relevant code in the kernel, the host machine will instead generate the MAC address in vstart and pass it to the kernel command line as is the case with a user-provided address. This will be quicker than the UML kernel's random generator.Describe alternatives you've considered Keep the patch. This is not an ideal solution since the user may not be aware of the patch (instead assuming a standard UML kernel) and the patch will require constant updating in-line with kernel development to prevent breaking.