Jan Damborsky wrote: > Dave Miner wrote: >> Jan Damborsky wrote: >>> Hi Dave, >>> >>> >>> Dave Miner wrote: >>>> Jan Damborsky wrote: ... >> >>> Thinking about this and comparing with ON network services, as you >>> pointed out, >>> there seem to be two levels of network configuration when "manual" >>> network strategy >>> is used with wanboot: >>> >>> [1] NIC configuration >>> --------------------- >>> I am thinking that part of code might become part of network/physical - >>> however, there would be at least following issues to be looked at: >>> >>> * netstrategy(1M) command is used to determine network configuration >>> strategy. >>> It doesn't work for our scenario, as it reports for "manual wanboot >>> case": >>> >>> # /sbin/netstrategy >>> ufs none none >>> >>> The desirable output would be something like >>> >>> # /sbin/netstrategy >>> ufs bge0 manual >>> >>> * /lib/svc/method/net-physical would need to be enhanced to be able >>> to configure >>> NIC when "manual" network configuration strategy is used >>> >> >> The whole "netstrategy" thing has always been pretty sketchy; if you >> look at the program, it's got a lot of heuristics that are based on >> older scenarios around diskless support, for example. >> >>> Another possibility would be to integrate that code into the kernel part >>> dealing with configuration of NIC in "boot from network scenario" - >>> this might >>> be actually better place as it seems to handle "boot from net" NIC >>> configurations >>> in other cases as well: >>> >> >> That would be interesting, and I think it would obviate some of the >> issues with netstrategy. Love to hear more about your ideas here, I >> haven't thought about it in a long time. > > Looking at the existing code, there seems to be two steps with respect > to bringing up network before premordial init(1) process is spawned: > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/main.c#main > > > > [1] plumbing boot NIC > --------------------- > If it is recognized that system was booted from network, > boot NIC is explicitly plumbed by calling strplumb(): > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/strplumb.c#strplumb > > > > It is either called from vfs_mountroot()->rootconf() if NFS is recognized > to be used as root filesystem or later from main(). > > [2] Configuring network for boot NIC (IP, netmask, default route) > ----------------------------------------------------------------- > While step [1] is always done if boot from network is detected, > this phase is only carried out if NFS is identified as root filesystem > (when I assume bringing up the network is the necessary condition > to be able to mount and access "/"). > > In that case, NIC as well as default route is configured from NFS > mount_root()->init_config(): > > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_dlinet.c#init_config > > > > It seems three mechanisms are tried as far as obtaining network > configuration is concerned: > > [a] boot properties (host-ip, subnet-mask, router-ip, ...) > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_dlinet.c#bp_netconfig > > > > [b] cached DHCP response (available as bootp-response property) > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_dlinet.c#dhcpinit > > > > [c] RARP > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_dlinet.c#whoami > > > > If we compare with what suggested fix for 9549 does, at the first glance > it seems it mimics behavior provided by [a]. I am wondering if we might > take advantage > of the fact that the code already exists. > > [b] would take care of configuring network in "dhcp" case. > > I am thinking about following questions we would need to answer: > > * Is there any special reason, why is network configured only for "root > on NFS", > but not for generic "boot from net" scenario ? >
From the kernel's point of view, it's booting from a ramdisk in the wanboot/AI case, it doesn't currently need to care where it came from. The "boot from net" definition has historically been having the real root mounted over NFS. So, it somewhat makes sense from that point of view that it's buried down in that sort of code path, though it's interesting that iSCSI didn't change this design. > * What problems would be encountered if we would like to let kernel always > take care of basic network configuration when system is booted from > network ? I can't think of any offhand, though there may be some subtle issues in figuring out that we did in fact boot from the network for the ramdisk case. Dave
