Steffen Maier (maier@xxxxxxxxxxxxxxxxxx) said: > On s390, udev may also automatically load (network) driver modules > (except for some hacking required for LCS and CTC). > > After loading driver modules, the probing as we are used to on other > platforms does not happen in the same way and _no_ (network) device > kernel structures are allocated at this point. We must not touch > devices which might be meant for another LPAR/VM. Hence, only the user > can decide which one (or few) of all the available devices should be > made available to the local Linux instance. Only then, a (network) > device gets allocated and the remaining configuration (e.g. IP on > layer 3) may very well be done as on any other hardware platform. Not that it's going to get much traction at this stage of s390's lifecycle, but this seems a fundamental design flaw - why would you trust each VM with making sure it doesn't step on other VMs' resources? Wouldn't this best be done in the hypervisor itself? > Yet, I don't think the steps for an actual allocation of a network > device on s390 should be integrated into NetworkManager. Those steps > are nothing more than a little pre-init we need on s390 to get our > devices going and available for e.g. HAL/NetworkManager. It's best to > code the pre-init at one place in the anaconda package No, it should be in udev. anaconda should not have hardware-specific code. > Also, NetworkManager relies on DHCP for e.g. auto-configuring network > layer addresses. NM can use static IP addressess, and we already have code for setting them up. There's no need for anything s390 specific here. > At the point where init.c would fork the loader, we would statically > replace this with an #ifdef and instead fork a stripped down > linuxrc.s390 which only contains the s390-specific device pre-init > including the necessary UI. Of course it needs some more glue to > support the IPC between init and the loader, which gets started later > on when the user logs on via ssh. > > What do you think? That's still doing it wrong... period. The idea is to eventually get away from a custom init entirely, as I understand it. Bill _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
