Re: [PATCH] Load FCP modules early for CD/DVD install (#184648)

[Bill Nottingham <notting redhat com>]

Steffen Maier (maier linux vnet ibm com) 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