[PATCH v2 1/2] module-setup: move kdump_setup_netdev early when handling iscsi

[WANG Chao]

Move kdump_setup_netdev in iscsi handling path early. Because when we
detect ibft or firmware iscsi session, we will bail out early, but still
need to bring up network device in 2nd kernel.

Signed-off-by: WANG Chao 
---
 dracut-module-setup.sh | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index dcebc47..b6218b3 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -434,8 +434,15 @@ kdump_setup_iscsi_device() {
         return 1
     fi

-    tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
     tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
+    netdev=$(/sbin/ip route get to ${tgt_ipaddr} | \
+        sed 's|.*dev (.*).*|\1|g')
+    srcaddr=$(echo $netdev | awk '{ print $3; exit }')
+    netdev=$(echo $netdev | awk '{ print $1; exit }')
+
+    kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
+
+    tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")

# get and set username and password details
     username=$(kdump_iscsi_get_rec_val ${path} "node.session.auth.username")
@@ -452,13 +459,6 @@ kdump_setup_iscsi_device() {

[ -n "$username_in" ] && userpwd_in_str=":$username_in:$password_in"

-    netdev=$(/sbin/ip route get to ${tgt_ipaddr} | \
-        sed 's|.*dev (.*).*|\1|g')
-    srcaddr=$(echo $netdev | awk '{ print $3; exit }')
-    netdev=$(echo $netdev | awk '{ print $1; exit }')
-
-    kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
-
     # prepare netroot= command line
     # FIXME: IPV6 addresses require explicit [] around $tgt_ipaddr
     # FIXME: Do we need to parse and set other parameters like protocol, port

[PATCH v2 2/2] Firmware iSCSI configuration support

[WANG Chao]

iscsi configuration can be exposed in /sys/firmware/ibft or
/sys/firmware/iscsi_bootX by iBFT or vendor specific driver (iBFT-like).
With "rd.iscsi.firmware" set in cmdline, dracut can bring up the iscsi
session regarding these exposed configurations. That means in this case,
it's not necessary to pass these configurations to 2nd kernel, because
dracut can directly use the exposed ones under sysfs.

If an iscsi session is based on firmware's configuration, then its
node.discovery_type will be "fw". If that's the case, we tell dracut
"rd.iscsi.firmware", and in 2nd kernel it will run "iscsistart -b" to
bring up the session regarding the firmware's exposed configurations.

Signed-off-by: WANG Chao 
---
 dracut-module-setup.sh | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index b6218b3..c6ec035 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -411,7 +411,19 @@ kdump_get_iscsi_initiator() {
     return 1
 }

-# No ibft handling yet.
+# Figure out if the iscsi session is based on iBFT or firmware
+kdump_handle_fw_iscsi() {
+    local netroot_conf="${initdir}/etc/cmdline.d/50iscsi.conf"
+
+    if [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]; then
+        # dracut will bring up the iscsi device from firmware's configuration
+        echo "rd.iscsi.firmware" >> $netroot_conf
+        return 0
+    fi
+
+    return 1
+}
+
 kdump_setup_iscsi_device() {
     local path=$1
     local tgt_name; local tgt_ipaddr;
@@ -442,6 +454,10 @@ kdump_setup_iscsi_device() {

kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr

+    if kdump_handle_fw_iscsi ${path}; then
+        return 0
+    fi
+
     tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")

# get and set username and password details

[Vivek Goyal]

On Wed, Nov 26, 2014 at 06:46:22PM +0800, WANG Chao wrote:
> Move kdump_setup_netdev in iscsi handling path early. Because when we
> detect ibft or firmware iscsi session, we will bail out early, but still
> need to bring up network device in 2nd kernel.

Chao, it says V2. Is it V2 of hardware iscsi support patches?

It is worth mentining in changelog that who will take care of rest
when ibft or firmware iscsi is in force. In fact what is firmware
iscsi?

Thanks
Vivek
> Signed-off-by: WANG Chao
>
> dracut-module-setup.sh | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index dcebc47..b6218b3 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -434,8 +434,15 @@ kdump_setup_iscsi_device() {
>          return 1
>      fi
> tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
>
> netdev=$(/sbin/ip route get to ${tgt_ipaddr} | \
>    sed 's|.*dev \(.*\).*|\1|g')
>
> srcaddr=$(echo $netdev | awk '{ print $3; exit }')
>
> netdev=$(echo $netdev | awk '{ print $1; exit }')
>
> kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
>
> tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>
> # get and set username and password details
> username=$(kdump_iscsi_get_rec_val ${path} "node.session.auth.username")
>
> @@ -452,13 +459,6 @@ kdump_setup_iscsi_device() {
>  [ -n "$username_in" ] && userpwd_in_str=":$username_in:$password_in"
>
> netdev=$(/sbin/ip route get to ${tgt_ipaddr} | \
>    sed 's|.*dev \(.*\).*|\1|g')
> srcaddr=$(echo $netdev | awk '{ print $3; exit }')
> netdev=$(echo $netdev | awk '{ print $1; exit }')
> kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
> # prepare netroot= command line
>    # FIXME: IPV6 addresses require explicit [] around $tgt_ipaddr
>    # FIXME: Do we need to parse and set other parameters like protocol, port
>
> -- 
> 1.9.3
>
> kexec mailing list
> [e-mail]
> https://lists.fedoraproject.org/mailman/listinfo/kexec

[PATCH v2 2/2] Firmware iSCSI configuration support

[Vivek Goyal]

On Wed, Nov 26, 2014 at 06:46:23PM +0800, WANG Chao wrote:
> iscsi configuration can be exposed in /sys/firmware/ibft or
> /sys/firmware/iscsi_bootX by iBFT or vendor specific driver (iBFT-like).
> With "rd.iscsi.firmware" set in cmdline, dracut can bring up the iscsi
> session regarding these exposed configurations. That means in this case,
> it's not necessary to pass these configurations to 2nd kernel, because
> dracut can directly use the exposed ones under sysfs.
>
> If an iscsi session is based on firmware's configuration, then its
> node.discovery_type will be "fw". If that's the case, we tell dracut
> "rd.iscsi.firmware", and in 2nd kernel it will run "iscsistart -b" to
> bring up the session regarding the firmware's exposed configurations.
> Signed-off-by: WANG Chao
>
> dracut-module-setup.sh | 18 +++++++++++++++++-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index b6218b3..c6ec035 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -411,7 +411,19 @@ kdump_get_iscsi_initiator() {
>      return 1
>  }
>
> -# No ibft handling yet.
> +# Figure out if the iscsi session is based on iBFT or firmware
> +kdump_handle_fw_iscsi() {
> local netroot_conf="${initdir}/etc/cmdline.d/50iscsi.conf"
> if [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]; then
>    # dracut will bring up the iscsi device from firmware's configuration
>    echo "rd.iscsi.firmware" >> $netroot_conf
>    return 0
> fi
> return 1
>
> +}
>
> kdump_setup_iscsi_device() {
>      local path=$1
>      local tgt_name; local tgt_ipaddr;
> @@ -442,6 +454,10 @@ kdump_setup_iscsi_device() {
>  kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
>
> if kdump_handle_fw_iscsi ${path}; then
>    return 0
> fi

So this function takes care of both hardware iscsi as well as ibft? 
What is this ibft mode (which is not hardware iscsi?)

Also I think we need to have better organization of code. current
kdump_setup_iscsi_device() primarily is code for setting up software
iscsi connections.

I think we should have 2-3 functions for setting up each type of
iscsi connection. kdump_setup_software_iscsi(), kdump_setup_hw_iscsi()
etc and call respective function based on type of connection we detect.

That way code should be more redabale.

Thanks
Vivek
>  tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>
>  # get and set username and password details
>
> -- 
> 1.9.3
>
> kexec mailing list
> [e-mail]
> https://lists.fedoraproject.org/mailman/listinfo/kexec

[WANG Chao]

On 12/04/14 at 03:42pm, Vivek Goyal wrote:
> On Wed, Nov 26, 2014 at 06:46:22PM +0800, WANG Chao wrote:
> > Move kdump_setup_netdev in iscsi handling path early. Because when we
> > detect ibft or firmware iscsi session, we will bail out early, but still
> > need to bring up network device in 2nd kernel.
>
> Chao, it says V2. Is it V2 of hardware iscsi support patches?

Yeah. V1 is the patchset with three patches. v1 used kernel command and
you didn't like that idea. So I totaly discard that method in v2.
> It is worth mentining in changelog that who will take care of rest
> when ibft or firmware iscsi is in force. In fact what is firmware
> iscsi?

Actually it's a term I made up. "Firmware iscsi" stands for hardware
iscsi and ibft. They both have the same attribute
"node.discovery_type=fw", so I figured maybe I can call it "firmware
iscsi"
> Thanks
> Vivek
> > Signed-off-by: WANG Chao
> >
> > dracut-module-setup.sh | 16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > index dcebc47..b6218b3 100755
> > --- a/dracut-module-setup.sh
> > +++ b/dracut-module-setup.sh
> > @@ -434,8 +434,15 @@ kdump_setup_iscsi_device() {
> >          return 1
> >      fi
> > tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> > tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
> >
> > netdev=$(/sbin/ip route get to ${tgt_ipaddr} | \
> >    sed 's|.*dev \(.*\).*|\1|g')
> >
> > srcaddr=$(echo $netdev | awk '{ print $3; exit }')
> >
> > netdev=$(echo $netdev | awk '{ print $1; exit }')
> >
> > kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
> >
> > tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> >
> > # get and set username and password details
> > username=$(kdump_iscsi_get_rec_val ${path} "node.session.auth.username")
> >
> > @@ -452,13 +459,6 @@ kdump_setup_iscsi_device() {
> >  [ -n "$username_in" ] && userpwd_in_str=":$username_in:$password_in"
> >
> > netdev=$(/sbin/ip route get to ${tgt_ipaddr} | \
> >    sed 's|.*dev \(.*\).*|\1|g')
> > srcaddr=$(echo $netdev | awk '{ print $3; exit }')
> > netdev=$(echo $netdev | awk '{ print $1; exit }')
> > kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
> > # prepare netroot= command line
> >    # FIXME: IPV6 addresses require explicit [] around $tgt_ipaddr
> >    # FIXME: Do we need to parse and set other parameters like protocol, port
> >
> > -- 
> > 1.9.3
> >
> > kexec mailing list
> > [e-mail]
> > https://lists.fedoraproject.org/mailman/listinfo/kexec

[PATCH v2 2/2] Firmware iSCSI configuration support

[WANG Chao]

On 12/04/14 at 03:51pm, Vivek Goyal wrote:
> On Wed, Nov 26, 2014 at 06:46:23PM +0800, WANG Chao wrote:
> > iscsi configuration can be exposed in /sys/firmware/ibft or
> > /sys/firmware/iscsi_bootX by iBFT or vendor specific driver (iBFT-like).
> > With "rd.iscsi.firmware" set in cmdline, dracut can bring up the iscsi
> > session regarding these exposed configurations. That means in this case,
> > it's not necessary to pass these configurations to 2nd kernel, because
> > dracut can directly use the exposed ones under sysfs.
> >
> > If an iscsi session is based on firmware's configuration, then its
> > node.discovery_type will be "fw". If that's the case, we tell dracut
> > "rd.iscsi.firmware", and in 2nd kernel it will run "iscsistart -b" to
> > bring up the session regarding the firmware's exposed configurations.
> > Signed-off-by: WANG Chao
> >
> > dracut-module-setup.sh | 18 +++++++++++++++++-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > index b6218b3..c6ec035 100755
> > --- a/dracut-module-setup.sh
> > +++ b/dracut-module-setup.sh
> > @@ -411,7 +411,19 @@ kdump_get_iscsi_initiator() {
> >      return 1
> >  }
> >
> > -# No ibft handling yet.
> > +# Figure out if the iscsi session is based on iBFT or firmware
> > +kdump_handle_fw_iscsi() {
> > local netroot_conf="${initdir}/etc/cmdline.d/50iscsi.conf"
> > if [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]; then
> >    # dracut will bring up the iscsi device from firmware's configuration
> >    echo "rd.iscsi.firmware" >> $netroot_conf
> >    return 0
> > fi
> > return 1
> >
> > +}
> >
> > kdump_setup_iscsi_device() {
> >      local path=$1
> >      local tgt_name; local tgt_ipaddr;
> > @@ -442,6 +454,10 @@ kdump_setup_iscsi_device() {
> >  kdump_setup_netdev $netdev $srcaddr $tgt_ipaddr
> >
> > if kdump_handle_fw_iscsi ${path}; then
> >    return 0
> > fi
>
> So this function takes care of both hardware iscsi as well as ibft? 
> What is this ibft mode (which is not hardware iscsi?)

Actually, I find some issues about this patch. When rd.iscsi.ibft or
ip=ibft is specified in 1st kernel cmdline, we must not bring up the
NIC.  Otherwise dracut will die and say it can't handle duplicated ip
configuration for same device.

I find hardware iscsi and ibft are very much complicated. I'm thinking
about we first support the systems booting from hardware iscsi or ibft?

After that if customer request other corner case for iscsi, we can
add the support case by case.
> Also I think we need to have better organization of code. current
> kdump_setup_iscsi_device() primarily is code for setting up software
> iscsi connections.
>
> I think we should have 2-3 functions for setting up each type of
> iscsi connection. kdump_setup_software_iscsi(), kdump_setup_hw_iscsi()
> etc and call respective function based on type of connection we detect.

Right. This sounds good to me.

Thanks
WANG Chao
> That way code should be more redabale.
>
> Thanks
> Vivek
> >  tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> >
> >  # get and set username and password details
> >
> > -- 
> > 1.9.3
> >
> > kexec mailing list
> > [e-mail]
> > https://lists.fedoraproject.org/mailman/listinfo/kexec

[PATCH v2 2/2] Firmware iSCSI configuration support

[Vivek Goyal]

On Fri, Dec 05, 2014 at 03:06:56PM +0800, WANG Chao wrote:

[..]
> Actually, I find some issues about this patch. When rd.iscsi.ibft or
> ip=ibft is specified in 1st kernel cmdline, we must not bring up the
> NIC.  Otherwise dracut will die and say it can't handle duplicated ip
> configuration for same device.
>
> I find hardware iscsi and ibft are very much complicated. I'm thinking
> about we first support the systems booting from hardware iscsi or ibft?

I am fine with handling two separately. But I am assuming hardware iscsi
always uses ibft?

Anyway, I think we need little more clarity on different fronts. I think
Chris Leech knows answers to those. So if you have questions, feel free
to send it to him.

Thanks
Vivek

[PATCH v2 2/2] Firmware iSCSI configuration support

[WANG Chao]

On 12/05/14 at 10:27am, Vivek Goyal wrote:
> On Fri, Dec 05, 2014 at 03:06:56PM +0800, WANG Chao wrote:
>
> [..]
> > Actually, I find some issues about this patch. When rd.iscsi.ibft or
> > ip=ibft is specified in 1st kernel cmdline, we must not bring up the
> > NIC.  Otherwise dracut will die and say it can't handle duplicated ip
> > configuration for same device.
> >
> > I find hardware iscsi and ibft are very much complicated. I'm thinking
> > about we first support the systems booting from hardware iscsi or ibft?
>
> I am fine with handling two separately. But I am assuming hardware iscsi
> always uses ibft?

In most the use cases, hardware iscsi uses ibft (/sys/firmware/ibft) or
ibft-like (/sys/firmware/iscsi_bootX). In most of ibft/ibft-like case,
the system is booting from iscsi.

So I figured since the kind of hardware iscsi the customers requested is
hardware iscsi as the boot disk, it's better to first support this to
avoid the complication of all kinds of hardware iscsi or ibft.

In the future, we can address other request (if any) case by case.
> Anyway, I think we need little more clarity on different fronts. I think
> Chris Leech knows answers to those. So if you have questions, feel free
> to send it to him.

Yeah, I'll ask him if I have further question.

Thanks
WANG Chao