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

WANG Chao chaowang at redhat.com
Wed Nov 26 04:20:22 UTC 2014


On 11/25/14 at 08:43am, Vivek Goyal wrote:
> On Tue, Nov 25, 2014 at 03:00:49PM +0800, WANG Chao wrote:
> > 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.
> > 
> 
> Why do you have to parse rd.iscsi.firmware in kdump module?

That's because I need to make sure that "rd.iscsi.firmware" is on the
cmdline, which in turn will make sure dracut will automatically bring up
the iscsi device. By "automatically", I mean dracut will run "iscsistart
-b" which reads configuration from firmware and start an iscsi session
using that configuration.

> 
> What if boot disk is software iscsi connection but there is another card
> in the system which is using hardware iscsi. In that case I think
> rd.iscsi.firmware will not be on command line?

Right.

And in this case, if the dump target is hardware iscsi, we will read the
configuration and pass it to 2nd kernel for dracut bringing up the
device. If the dump target is software iscsi, we will also do that.

> 
> I don't think that you should have to parse kernel command line to figure
> out if a iscsi connection is hw one or software one. In fact kenrel
> command line does not tell you that information.

No. I'll look into "iface.transport_name" to determine if it's hardware
iscsi or not. And I check "rd.iscsi.firmware" to make sure that dracut
will handle it automatically. If it's lack of "rd.iscsi.firmware", we
have to pass the hardware iscsi configuration to 2nd kernel.

Thanks
WANG Chao


More information about the kexec mailing list