[PATCH 1/3] module-setup: add two functions to determine hardware iscsi

WANG Chao chaowang at redhat.com
Tue Nov 25 07:00:49 UTC 2014


On 11/24/14 at 05:38pm, Vivek Goyal wrote:
> On Thu, Nov 13, 2014 at 03:58:13PM +0800, WANG Chao wrote:
> > If hardware iscsi is configured, we don't have to pass the setup information
> > to 2nd kernel. Because with cmdline argument "rd.iscsi.firmware", dracut
> > will automatically retrieve the setup information from hardware's firmware.
> > 
> > Add two functions to do the check. One is checking if we have
> > "rd.iscsi.firmware" or its equivalents specified in kernel cmdline. The
> > other is to check if the current iscsi session is hardware iscsi.
> > 
> > I read some iscsi code and I also talked with storage QE. It's confirmed
> > that software iscsi will use "tcp" transport class while hardware iscsi
> > will use like "be2iscsi" "bnx2i" transport class. It's ok to use the
> > transport name of an iface of a scsi session to determine hardware iscsi
> > or not.
> > 
> > Signed-off-by: WANG Chao <chaowang at redhat.com>
> > ---
> >  dracut-module-setup.sh | 32 ++++++++++++++++++++++++++++++++
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > index dcebc47..bca21ea 100755
> > --- a/dracut-module-setup.sh
> > +++ b/dracut-module-setup.sh
> > @@ -411,6 +411,38 @@ kdump_get_iscsi_initiator() {
> >      return 1
> >  }
> >  
> > +# Determine hardware iscsi by an iface's transport class.
> > +# If transport class is tcp, it's software iscsi.
> > +# If it's be2iscsi, bnx2i, cxgb3i, cxgb4i, it's hardware iscsi.
> > +kdump_is_iscsi_hw_session() {
> > +    if [ "$(kdump_iscsi_get_rec_val $1 "iface.transport_name")" = tcp ]; then
> > +        return 1
> > +    fi
> > +
> > +    return 0
> > +}
> > +
> > +# kernel cmdline must contain these either of the following arguments
> > +# for booting off hardware iSCSI:
> > +# rd.iscsi.firmware[=1], iscsi_firmware
> > +kdump_is_iscsi_hw_cmdline() {
> > +    local cmdline
> > +
> > +    cmdline="$(cat /proc/cmdline)"
> > +
> > +    for arg in $cmdline; do
> > +        case "$arg" in
> > +            "rd.iscsi.firmware" |\
> > +            "rd.iscsi.firmware=1" |\
> > +            "iscsi_firmware")
> > +                return 0
> > +                ;;
> > +        esac
> > +    done
> 
> What's the use of this funciton. While building initramfs, why kdump
> module will care what's being passed on commandline?
> 
> Also this code will run during initramfs generation and not when 
> initramfs is being mounted. So if you read /proc/cmdline, you are
> reading the command line of running kernel when initramfs is being
> generated. Does not sound right to me.

User configures boot from iscsi (hardware iscsi), kernel cmdline
must contain "rd.iscsi.firmware". dracut will detect "rd.iscsi.firmware"
and start a hardware iscsi connection. In other words,
"rd.iscsi.firmware" is mandatory for hardware iscsi boot.

Now the issue is dracut will take care of bringing up hardware iscsi
device for boot. We (kdump module) must not pass down the information to
dracut again, otherwise the same device will be brought up twice. One
time is dracut reads "rd.iscsi.firmware" and run "iscsistart -b", the
other time is dracut reads "netroot=iscsi.." (passed by kdump) and run
"iscsistart xxx".

We don't want to run into this kind of race. That's why we should skip
the device which will be handled by dracut without kdump.

To determine what will be skipped, I go with the following ways:
- First check if "rd.iscsi.firmware" is on currently kernel cmdline. If
  it's not, dracut will not handle any device automatically. Even the
  connection is hardware iscsi, it could be setup'd manually.
- Second check if the iscsi connection is hardware iscsi connection. If
  it's not, it's software iscsi connection and we should pass down its
  setup information to 2nd kernel. This happens when there's multiple
  iscsi connections in the system, some are hardware iscsi from which
  the system boots, some are software iscsi which brought up by iscsid
  service.

What do you think?

Thanks
WANG Chao


More information about the kexec mailing list