This patchset adds support for hardware iscsi. It's previously one big patch, and now I break it down to three.
Along with this patch, I add the infrastructure of determine iBFT, but it's not complete yet, because I don't know how to determine it in a reliable way. Mark this part as FIXME. Perhaps in the future someone ask for iBFT and we can gather some data there, and finish this part.
WANG Chao (3): module-setup: add two functions to determine hardware iscsi module-setup: add two functions to determine iBFT Hardware iSCSI support
dracut-module-setup.sh | 81 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 80 insertions(+), 1 deletion(-)
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@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 + + return 1 +} + # No ibft handling yet. kdump_setup_iscsi_device() { local path=$1
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@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.
Thanks Vivek
- return 1
+}
# No ibft handling yet. kdump_setup_iscsi_device() { local path=$1 -- 1.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
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@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
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@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?
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?
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.
Thanks Vivek
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@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
If iBFT (iscsi Boot Firmware Table) is configured, we don't have to pass the setup information to 2nd kernel. Because with cmdline argument "rd.iscsi.ibft", dracut will automatically retrieve the setup information from BIOS's ROM or network device's optional-ROM (not from HBA's firmware)
Add two functions to do the check. One is checking if we have "rd.iscsi.ibft" or its equivalents specified in kernel cmdline. The other is to check if the current iscsi session is iBFT.
Because I don't find a reliable way to tell if an iscsi session is using the configurations from iBFT, I marked the second functions as "FIXME" and it always returns false. That means we don't handle iBFT yet. In the future, if someone is asking iBFT support, we can gather some data and finish the work.
Signed-off-by: WANG Chao chaowang@redhat.com --- dracut-module-setup.sh | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index bca21ea..780601a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -422,6 +422,11 @@ kdump_is_iscsi_hw_session() { return 0 }
+# FIXME: determine iBFT +kdump_is_iscsi_ibft_session() { + return 1 +} + # kernel cmdline must contain these either of the following arguments # for booting off hardware iSCSI: # rd.iscsi.firmware[=1], iscsi_firmware @@ -443,6 +448,27 @@ kdump_is_iscsi_hw_cmdline() { return 1 }
+# kernel cmdline must contain these either of the following arguments +# for booting off iBFT: +# rd.iscsi.ibft[=1], ip=ibft +kdump_is_iscsi_ibft_cmdline() { + local cmdline + + cmdline="$(cat /proc/cmdline)" + + for arg in $cmdline; do + case "$arg" in + "rd.iscsi.ibft" |\ + "rd.iscsi.ibft=1" |\ + "ip=ibft") + return 0 + ;; + esac + done + + return 1 +} + # No ibft handling yet. kdump_setup_iscsi_device() { local path=$1
Currently we retrieve all the necessary information of an iSCSI session and pass them to 2nd kernel. This is wrong way to go for hardware iscsi, because dracut has already had its own infrastructure to do bring up any iscsi device configured in firmware of an HBA (Host Bus Bridge).
This patch will determine if an iscsi session is established by firmware configured iscsi. If it does, then we don't pass anything down to 2nd kernel. dracut will handle it.
Signed-off-by: WANG Chao chaowang@redhat.com --- dracut-module-setup.sh | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 780601a..18f2294 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -469,7 +469,24 @@ kdump_is_iscsi_ibft_cmdline() { return 1 }
-# No ibft handling yet. +# Sanity check if an iscsi session is established by iBFT or firmware +kdump_is_iscsi_fw() { + + if kdump_is_iscsi_hw_cmdline && kdump_is_iscsi_hw_session $1; then + return 0 + fi + + if kdump_is_iscsi_ibft_cmdline && kdump_is_iscsi_ibft_session $1; then + return 0 + fi + + return 1 +} + +# +# FIXME: No ibft handling yet. We need to finish the work in +# kdump_is_iscsi_ibft_session() +# kdump_setup_iscsi_device() { local path=$1 local tgt_name; local tgt_ipaddr; @@ -492,6 +509,10 @@ kdump_setup_iscsi_device() { return 1 fi
+ if kdump_is_iscsi_fw ${path}; then + return 0 + fi + tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name") tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
On Thu, Nov 13, 2014 at 03:58:43PM +0800, WANG Chao wrote:
Currently we retrieve all the necessary information of an iSCSI session and pass them to 2nd kernel. This is wrong way to go for hardware iscsi, because dracut has already had its own infrastructure to do bring up any iscsi device configured in firmware of an HBA (Host Bus Bridge).
This patch will determine if an iscsi session is established by firmware configured iscsi. If it does, then we don't pass anything down to 2nd kernel. dracut will handle it.
Signed-off-by: WANG Chao chaowang@redhat.com
dracut-module-setup.sh | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index 780601a..18f2294 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -469,7 +469,24 @@ kdump_is_iscsi_ibft_cmdline() { return 1 }
-# No ibft handling yet. +# Sanity check if an iscsi session is established by iBFT or firmware +kdump_is_iscsi_fw() {
- if kdump_is_iscsi_hw_cmdline && kdump_is_iscsi_hw_session $1; then
return 0- fi
Not sure why are we trying to check cmdline here?
- if kdump_is_iscsi_ibft_cmdline && kdump_is_iscsi_ibft_session $1; then
return 0- fi
I think we can get rid of ibft functionality for now and introduce it once we know what to do.
Thanks Vivek
On Thu, Nov 13, 2014 at 03:58:42PM +0800, WANG Chao wrote:
If iBFT (iscsi Boot Firmware Table) is configured, we don't have to pass the setup information to 2nd kernel. Because with cmdline argument "rd.iscsi.ibft", dracut will automatically retrieve the setup information from BIOS's ROM or network device's optional-ROM (not from HBA's firmware)
Add two functions to do the check. One is checking if we have "rd.iscsi.ibft" or its equivalents specified in kernel cmdline. The other is to check if the current iscsi session is iBFT.
Because I don't find a reliable way to tell if an iscsi session is using the configurations from iBFT, I marked the second functions as "FIXME" and it always returns false. That means we don't handle iBFT yet. In the future, if someone is asking iBFT support, we can gather some data and finish the work.
If we can't figure out if a connection is using iBFT or not, then we should not have this patch.
I am Ccing Ewan and Andy Grover. May be they have an idea how to figure out if a particular session/connection is using iBFT or not.
Thanks Vivek
Signed-off-by: WANG Chao chaowang@redhat.com
dracut-module-setup.sh | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh index bca21ea..780601a 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -422,6 +422,11 @@ kdump_is_iscsi_hw_session() { return 0 }
+# FIXME: determine iBFT +kdump_is_iscsi_ibft_session() {
- return 1
+}
# kernel cmdline must contain these either of the following arguments # for booting off hardware iSCSI: # rd.iscsi.firmware[=1], iscsi_firmware @@ -443,6 +448,27 @@ kdump_is_iscsi_hw_cmdline() { return 1 }
+# kernel cmdline must contain these either of the following arguments +# for booting off iBFT: +# rd.iscsi.ibft[=1], ip=ibft +kdump_is_iscsi_ibft_cmdline() {
- local cmdline
- cmdline="$(cat /proc/cmdline)"
- for arg in $cmdline; do
case "$arg" in"rd.iscsi.ibft" |\"rd.iscsi.ibft=1" |\"ip=ibft")return 0;;esac- done
- return 1
+}
# No ibft handling yet. kdump_setup_iscsi_device() { local path=$1 -- 1.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On Thu, Nov 13, 2014 at 03:56:34PM +0800, WANG Chao wrote:
This patchset adds support for hardware iscsi. It's previously one big patch, and now I break it down to three.
Hi Chao,
Last time I mentioned that first we need to move some pieces which are in kdump to iscsi module of dracut. You were of the opinion that there are no such pieces.
I am looking at the code now and I am wondering that why following should not go in 95iscsi/ module.
kdump_check_iscsi_targets().
This function seems to go through all the block devices. I think it should be dracut's job to call in to iscsi module with each block device and see if any of these is iscsi backed block device and let iscsi module pull in relevant dependencies.
For example, look at check() function of 95iscsi/module-setup.sh and it does check if the passed in device is iscsi device or not.
module-setup.sh also seems to be pulling in right modules. What I am not sure is that where is it preparing right configuation info which is passed on command line to dracut. rd.iscsi= etc.
Kdump module should ideally be concerned with only setting up kdump related configuration and not anything else. That's how dracut is structured. Now if kdump module also starts configuring iscsi configurations, then it is violation of that structure.
Thanks Vivek
Along with this patch, I add the infrastructure of determine iBFT, but it's not complete yet, because I don't know how to determine it in a reliable way. Mark this part as FIXME. Perhaps in the future someone ask for iBFT and we can gather some data there, and finish this part.
WANG Chao (3): module-setup: add two functions to determine hardware iscsi module-setup: add two functions to determine iBFT Hardware iSCSI support
dracut-module-setup.sh | 81 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 80 insertions(+), 1 deletion(-)
-- 1.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On 11/17/14 at 04:14pm, Vivek Goyal wrote:
On Thu, Nov 13, 2014 at 03:56:34PM +0800, WANG Chao wrote:
This patchset adds support for hardware iscsi. It's previously one big patch, and now I break it down to three.
Hi Chao,
Last time I mentioned that first we need to move some pieces which are in kdump to iscsi module of dracut. You were of the opinion that there are no such pieces.
I am looking at the code now and I am wondering that why following should not go in 95iscsi/ module.
kdump_check_iscsi_targets().
This function seems to go through all the block devices. I think it should be dracut's job to call in to iscsi module with each block device and see if any of these is iscsi backed block device and let iscsi module pull in relevant dependencies.
For example, look at check() function of 95iscsi/module-setup.sh and it does check if the passed in device is iscsi device or not.
module-setup.sh also seems to be pulling in right modules. What I am not sure is that where is it preparing right configuation info which is passed on command line to dracut. rd.iscsi= etc.
Yes, kdump_check_iscsi_targets() will go throught all the necessary block devices and setup the cmdline if iscsi device is found.
In 95iscsi/module-setup.sh::check(), it will also go through all the necessary devices. But only will it pull in the binaries and other dependencies for setting up iscsi.
This kind of separation makes sense to me. I think in case of iscsi device, dracut is more designed like "tell me what how exactly you want to setup the iscsi device and I'll bring it up for you" or "I can't simply guess what's the configuration you like for this device", given the fact that iscsi setup is complicated and dracut provides a rich set of iscsi cmdline argument.
I think it's more like a design issue. I like the way it does now and it does exactly the same thing for network devices. You have to tell dracut what's network topology you want, "I want a bridge interface over bonding" not just "setup the network as the system does for me now".
My point is dracut is designed the way it needs to be told how exactly it should work. If it's doing too much, it may end up doing something unexpected.
Thanks WANG Chao
Kdump module should ideally be concerned with only setting up kdump related configuration and not anything else. That's how dracut is structured. Now if kdump module also starts configuring iscsi configurations, then it is violation of that structure.
Thanks Vivek
Along with this patch, I add the infrastructure of determine iBFT, but it's not complete yet, because I don't know how to determine it in a reliable way. Mark this part as FIXME. Perhaps in the future someone ask for iBFT and we can gather some data there, and finish this part.
WANG Chao (3): module-setup: add two functions to determine hardware iscsi module-setup: add two functions to determine iBFT Hardware iSCSI support
dracut-module-setup.sh | 81 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 80 insertions(+), 1 deletion(-)
-- 1.9.3
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec
On Wed, Nov 19, 2014 at 02:48:34PM +0800, WANG Chao wrote:
On 11/17/14 at 04:14pm, Vivek Goyal wrote:
On Thu, Nov 13, 2014 at 03:56:34PM +0800, WANG Chao wrote:
This patchset adds support for hardware iscsi. It's previously one big patch, and now I break it down to three.
Hi Chao,
Last time I mentioned that first we need to move some pieces which are in kdump to iscsi module of dracut. You were of the opinion that there are no such pieces.
I am looking at the code now and I am wondering that why following should not go in 95iscsi/ module.
kdump_check_iscsi_targets().
This function seems to go through all the block devices. I think it should be dracut's job to call in to iscsi module with each block device and see if any of these is iscsi backed block device and let iscsi module pull in relevant dependencies.
For example, look at check() function of 95iscsi/module-setup.sh and it does check if the passed in device is iscsi device or not.
module-setup.sh also seems to be pulling in right modules. What I am not sure is that where is it preparing right configuation info which is passed on command line to dracut. rd.iscsi= etc.
Yes, kdump_check_iscsi_targets() will go throught all the necessary block devices and setup the cmdline if iscsi device is found.
In 95iscsi/module-setup.sh::check(), it will also go through all the necessary devices. But only will it pull in the binaries and other dependencies for setting up iscsi.
This kind of separation makes sense to me. I think in case of iscsi device, dracut is more designed like "tell me what how exactly you want to setup the iscsi device and I'll bring it up for you" or "I can't simply guess what's the configuration you like for this device", given the fact that iscsi setup is complicated and dracut provides a rich set of iscsi cmdline argument.
I think it's more like a design issue. I like the way it does now and it does exactly the same thing for network devices. You have to tell dracut what's network topology you want, "I want a bridge interface over bonding" not just "setup the network as the system does for me now".
My point is dracut is designed the way it needs to be told how exactly it should work. If it's doing too much, it may end up doing something unexpected.
Hi Chao,
Ok, I agree. Right now dracut modules seems to be pulling in right modules, dependencies and some configuration files.
Rest of the device specific configuration it seems to be expecting on command line.
I think for the time being let us continue to have what we have.
Thanks Vivek
-
Vivek Goyal -
WANG Chao