On 24/09/15 22:52, Andrew Stuart wrote:
####Core kernel build functionality - has an *inward* perspective - builds a
unikernel and deals only with the inner workings of the unikernel.
Some ideas (not maybe some of which are current behaviour?):
** Use initramfs / initrd or similar for built in rootfs
https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
** initramfs loaded by grub along with kernel at boot
** Kernels are diskless - no requirement for disk beyond initrd rootfs
** Kernel automounts all attached block volumes by default unless overridden by
json.cfg
** Kernel configures itself with DHCP if available unless overridden with
specific network configuration in json.cfg
** json.cfg file is stored in initial ramfs, or may be overridden by being
passed in text of json.cfg as a kernel argument at launch
Off-by-default is the only sensible policy. It is way too difficult to
secure systems which are smart behind your back. Even software which
provides an "everything" example config alone sucks bad enough, since
you need to figure out what to remove instead of adding what you want.
Something where the "everything" is on by default by not even being
explicitly presented to the user is a disaster. I don't want to hear
"hey thanks I discovered that your software exported my sensitive data
to the internet" feedback.
Again, the intent is to make it possible to build fancy stuff, so if
someone wants to shoot themselves either to the moon or in the foot,
they can. However, that fancy stuff is not being discussed in this thread.
json.cfg:
** defines configuration that happens INSIDE the unikernel
** does not attempt to specify anything about what configuration happens
OUTSIDE the unikernel
** specifies names of required block devices and their mountpoints
** specifies network device configuration
** other things kernel needs to configure?
** json.cfg not needed at all for example in a diskless config where there a no
block devices to mount, and where only DHCP is required
No. For example, how does the application know its command line params
or env? Sure, I can come up with examples where cfg is really not
needed: hello world printing static message, no i/o devices -- and I
often even run that case without the cfg file when I'm developing
something. However, such special cases are not relevant for the grand
design.
Where possible and where is makes sense, the build process provides EXTERNAL VM
host configuration information somehow, suggesting for example the command line
required to boot with the various target platforms. Maybe this is just text or
some sort of configuration json structure.
I'd say that should be provided only by the documentation, esp. the
tutorials.
####The hardest bit (for me)
The hardest bit currently is trying to understand network device naming and
what names are needed by what target and how to map the kernel’s naming to the
external name. I’m still trying to figure this out. Not sure if this needs
code or just written explanation. Feels a bit like black magic at the moment
to work our network device names. I need to dive into the code to try to fully
understand this area.
It's true that the naming is .. uhm .. suboptimal.
The problem is that the INSIDE config has no way of knowing how the
devices in the OUTSIDE config may be enumerated at runtime. If you have
only one Ethernet device, it's easy'ish, but beyond that it's always
unsure('ish).
Linux has (or at least had?) the advantage of using eth<n> for the
devices. There was a loooong flamewar about converting to that scheme
on the NetBSD lists ~15(?) years ago, so not holding my breath that
NetBSD is going to migrate away from the driver<n> scheme any time
before the heat death of the universe.
So, what can we do in the INSIDE config to address the problem you
pointed out?
We could add something like "bus:identifier", but is that any easier to
configure, or actually harder and even more volatile?
We could define some pseudo-identifier, like nif<n>, and say that nif<n>
will be the nth "actual NIC"(*) when sorted alphabetically. Not sure
that's particularly helpful either, though it solves things for when
there is exactly one hardware interface.
Finally, we can do something like macif:<ac:tu:al:mac:he:re>. As long
as you know the external MAC, you don't have to worry about anything
else. The issue there is that you always need a pair of IN+OUTSIDE with
that model.
Maybe we need both nif and macif? Might be difficult to convince NetBSD
to accept such aliasing code, though. So, I don't know. Maybe the best
we can do is to document it's vioif<n> for virtio, xenif<n> for Xen pv
and for the rest you should do a test boot first.
Again, the goal is to find a solution which works for *all* scenarios
*in the scope*, not just one or two which look particularly interesting
today. It's a hard enough problem already, let's not make it harder by
getting sidetracked with special cases which don't cut the global mustard.
