Re: [REPOST PATCH] Add iSCSI IBFT support (v0.4)
On Wed, Nov 28, 2007 at 07:34:22PM -0400, Konrad Rzeszutek wrote:
>
> This patch adds /sysfs/firmware/ibft/[initiator|targetX|ethernetX]
> directories along with text properties which export the the iSCSI Boot
> Firmware Table (iBFT) structure.
>
> What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI
> tools to extract from the machine NICs the iSCSI connection information
> so that they can automagically mount the iSCSI share/target. Currently
> the iSCSI information is hard-coded in the initrd.
>
> For full details of the IBFT structure please take a look at:
> ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf
>
>
> Signed-off-by: Konrad Rzeszutek <[EMAIL PROTECTED]>
Here is an updated version which provides an attribute symlink (in the
ethernetX directory) called 'device' to the NIC device, instead of
exporting a 'pci_bdf' file which had the "bus:slot:func" values.
Review would be much appreciated.
Signed-off-by: Konrad Rzeszutek <[EMAIL PROTECTED]>
diff --git a/Documentation/ABI/testing/sysfs-ibft
b/Documentation/ABI/testing/sysfs-ibft
new file mode 100644
index 000..941ad9f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-ibft
@@ -0,0 +1,31 @@
+What: /sys/firmware/ibft/initiator
+Date: November 2007
+Contact: Konrad Rzeszutek <[EMAIL PROTECTED]>
+Description: The /sys/firmware/ibft/initiator directory will contain
+ files that expose the iSCSI Boot Firmware Table initiator data.
+ Usually this contains the Initiator name.
+
+What: /sys/firmware/ibft/targetX
+Date: November 2007
+Contact: Konrad Rzeszutek <[EMAIL PROTECTED]>
+Description: The /sys/firmware/ibft/targetX directory will contain
+ files that expose the iSCSI Boot Firmware Table target data.
+ Usually this contains the target's IP address, boot LUN,
+ target name, and what NIC it is associated with. It can also
+ contain the CHAP name (and password), the reverse CHAP
+ name (and password)
+
+What: /sys/firmware/ibft/ethernetX
+Date: November 2007
+Contact: Konrad Rzeszutek <[EMAIL PROTECTED]>
+Description: The /sys/firmware/ibft/ethernetX directory will contain
+ files that expose the iSCSI Boot Firmware Table NIC data.
+ This can this can the IP address, MAC, and gateway of the NIC.
+
+What: /sys/firmware/ibft/extensionX
+Date: November 2007
+Contact: Konrad Rzeszutek <[EMAIL PROTECTED]>
+Description: The /sys/firmware/ibft/extensionX directory will contain
+ files that expose the iSCSI Boot Firmware Table extension data.
+ The extended data structure is not supported so there would be
+ no files in this directory.
diff --git a/arch/x86/kernel/setup_32.c b/arch/x86/kernel/setup_32.c
index e1e18c3..7c36a28 100644
--- a/arch/x86/kernel/setup_32.c
+++ b/arch/x86/kernel/setup_32.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -148,6 +149,20 @@ static inline void copy_edd(void)
}
#endif
+#if defined(CONFIG_ISCSI_IBFT_FIND)
+static void __init reserve_ibft_region(void)
+{
+ unsigned int ibft_len;
+
+ ibft_len = find_ibft();
+ if (ibft_len)
+ reserve_bootmem((unsigned int)ibft_phys,
+ PAGE_ALIGN(ibft_len));
+}
+#else
+static void __init reserve_ibft_region(void) { }
+#endif
+
int __initdata user_defined_memmap = 0;
/*
@@ -496,6 +511,7 @@ void __init setup_bootmem_allocator(void)
}
#endif
reserve_crashkernel();
+ reserve_ibft_region();
}
/*
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 30d94d1..d5b73c6 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -198,6 +199,20 @@ static inline void copy_edd(void)
}
#endif
+#if defined(CONFIG_ISCSI_IBFT_FIND)
+static void __init reserve_ibft_region(void)
+{
+ unsigned int ibft_len;
+
+ ibft_len = find_ibft();
+ if (ibft_len)
+ reserve_bootmem_generic((unsigned long)ibft_phys,
+ PAGE_ALIGN(ibft_len));
+}
+#else
+static void __init reserve_ibft_region(void) { }
+#endif
+
#ifdef CONFIG_KEXEC
static void __init reserve_crashkernel(void)
{
@@ -403,6 +418,7 @@ void __init setup_arch(char **cmdline_p)
}
#endif
reserve_crashkernel();
+ reserve_ibft_region();
paging_init();
#ifdef CONFIG_PCI
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 05f02a3..e2f7208 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -93,4 +93,23 @@ config DMIID
information from userspace through /sys/class/dmi/id/ or if you want
DMI-based module auto-loading.
Re: [REPOST PATCH] Add iSCSI IBFT support (v0.4)
On Wed, Nov 28, 2007 at 07:34:22PM -0400, Konrad Rzeszutek wrote:
This patch adds /sysfs/firmware/ibft/[initiator|targetX|ethernetX]
directories along with text properties which export the the iSCSI Boot
Firmware Table (iBFT) structure.
What is iSCSI Boot Firmware Table? It is a mechanism for the iSCSI
tools to extract from the machine NICs the iSCSI connection information
so that they can automagically mount the iSCSI share/target. Currently
the iSCSI information is hard-coded in the initrd.
For full details of the IBFT structure please take a look at:
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/ibm_iscsi_boot_firmware_table_v1.02.pdf
Signed-off-by: Konrad Rzeszutek [EMAIL PROTECTED]
Here is an updated version which provides an attribute symlink (in the
ethernetX directory) called 'device' to the NIC device, instead of
exporting a 'pci_bdf' file which had the bus:slot:func values.
Review would be much appreciated.
Signed-off-by: Konrad Rzeszutek [EMAIL PROTECTED]
diff --git a/Documentation/ABI/testing/sysfs-ibft
b/Documentation/ABI/testing/sysfs-ibft
new file mode 100644
index 000..941ad9f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-ibft
@@ -0,0 +1,31 @@
+What: /sys/firmware/ibft/initiator
+Date: November 2007
+Contact: Konrad Rzeszutek [EMAIL PROTECTED]
+Description: The /sys/firmware/ibft/initiator directory will contain
+ files that expose the iSCSI Boot Firmware Table initiator data.
+ Usually this contains the Initiator name.
+
+What: /sys/firmware/ibft/targetX
+Date: November 2007
+Contact: Konrad Rzeszutek [EMAIL PROTECTED]
+Description: The /sys/firmware/ibft/targetX directory will contain
+ files that expose the iSCSI Boot Firmware Table target data.
+ Usually this contains the target's IP address, boot LUN,
+ target name, and what NIC it is associated with. It can also
+ contain the CHAP name (and password), the reverse CHAP
+ name (and password)
+
+What: /sys/firmware/ibft/ethernetX
+Date: November 2007
+Contact: Konrad Rzeszutek [EMAIL PROTECTED]
+Description: The /sys/firmware/ibft/ethernetX directory will contain
+ files that expose the iSCSI Boot Firmware Table NIC data.
+ This can this can the IP address, MAC, and gateway of the NIC.
+
+What: /sys/firmware/ibft/extensionX
+Date: November 2007
+Contact: Konrad Rzeszutek [EMAIL PROTECTED]
+Description: The /sys/firmware/ibft/extensionX directory will contain
+ files that expose the iSCSI Boot Firmware Table extension data.
+ The extended data structure is not supported so there would be
+ no files in this directory.
diff --git a/arch/x86/kernel/setup_32.c b/arch/x86/kernel/setup_32.c
index e1e18c3..7c36a28 100644
--- a/arch/x86/kernel/setup_32.c
+++ b/arch/x86/kernel/setup_32.c
@@ -39,6 +39,7 @@
#include linux/efi.h
#include linux/init.h
#include linux/edd.h
+#include linux/iscsi_ibft.h
#include linux/nodemask.h
#include linux/kexec.h
#include linux/crash_dump.h
@@ -148,6 +149,20 @@ static inline void copy_edd(void)
}
#endif
+#if defined(CONFIG_ISCSI_IBFT_FIND)
+static void __init reserve_ibft_region(void)
+{
+ unsigned int ibft_len;
+
+ ibft_len = find_ibft();
+ if (ibft_len)
+ reserve_bootmem((unsigned int)ibft_phys,
+ PAGE_ALIGN(ibft_len));
+}
+#else
+static void __init reserve_ibft_region(void) { }
+#endif
+
int __initdata user_defined_memmap = 0;
/*
@@ -496,6 +511,7 @@ void __init setup_bootmem_allocator(void)
}
#endif
reserve_crashkernel();
+ reserve_ibft_region();
}
/*
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 30d94d1..d5b73c6 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -33,6 +33,7 @@
#include linux/acpi.h
#include linux/kallsyms.h
#include linux/edd.h
+#include linux/iscsi_ibft.h
#include linux/mmzone.h
#include linux/kexec.h
#include linux/cpufreq.h
@@ -198,6 +199,20 @@ static inline void copy_edd(void)
}
#endif
+#if defined(CONFIG_ISCSI_IBFT_FIND)
+static void __init reserve_ibft_region(void)
+{
+ unsigned int ibft_len;
+
+ ibft_len = find_ibft();
+ if (ibft_len)
+ reserve_bootmem_generic((unsigned long)ibft_phys,
+ PAGE_ALIGN(ibft_len));
+}
+#else
+static void __init reserve_ibft_region(void) { }
+#endif
+
#ifdef CONFIG_KEXEC
static void __init reserve_crashkernel(void)
{
@@ -403,6 +418,7 @@ void __init setup_arch(char **cmdline_p)
}
#endif
reserve_crashkernel();
+ reserve_ibft_region();
paging_init();
#ifdef CONFIG_PCI
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 05f02a3..e2f7208 100644
--- a/drivers/firmware/Kconfig
+++
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
> > > > /sys/firmware/ibft/ethernet0/pci-bdf > > 5:1:0 > > shouldn't this somehow also have a symlink to the kernels ethX view of > ethernet devices? > (and if so.. how much of the info is duplicated..) That NIC is used by the NIC firmware (or the BIOS) to negotiate the iSCSI target. The information that is in this directory is what the BIOS used (note past tense) which might very well be completly different from what Linux uses. My rationale behind _not_ linking to ethX view was that it could be confusing and not entirely useful for users: "It says that _this_ NIC, with this IP, uses this iSCSI target. But Linux is using a completly different NIC (and IP) to setup a iSCSI connection to the same iSCSI target!?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
/sys/firmware/ibft/ethernet0/pci-bdf 5:1:0 shouldn't this somehow also have a symlink to the kernels ethX view of ethernet devices? (and if so.. how much of the info is duplicated..) That NIC is used by the NIC firmware (or the BIOS) to negotiate the iSCSI target. The information that is in this directory is what the BIOS used (note past tense) which might very well be completly different from what Linux uses. My rationale behind _not_ linking to ethX view was that it could be confusing and not entirely useful for users: It says that _this_ NIC, with this IP, uses this iSCSI target. But Linux is using a completly different NIC (and IP) to setup a iSCSI connection to the same iSCSI target!? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
> > > I didn't realize an external file, outside of your changes, needed this > > > function. If it does, then perhaps you need to just place it elsewhere. > > > > The fundamental problem is that 'find_ibft' ought to be available > > from anywhere (or at least from the iscsi_ibft.c) so that the iscsi_ibft > > module can be loaded on any platform. But on x86, it needs to be called > > from setup_[32|64].c because the IBFT can be located anywhere > > between 512KB and 1MB - and the E820 does not neccesarily have to > > exclude that region. Hence the patch I proposed implements a > > 'reserve_ibft_region' code which would reserve the region of memory > > found by 'find_ibft' so that it can be preserved when iscsi_ibft > > module is actually loaded. > > > > It ends up that there are three consumers of 'find_ibft': > > a) the module itself (iscsi_ibft.c) > > b) setup_32.c > > c) setup_64.c > > > > The first choice, which looked the most flexible, was to have it > > in iscsi_ibft.h file. > > The second one, which would inhibit the user from making iscsi_ibft > > a module, would be to move it to iscsi_ibft.c and make it > > EXPORT_SYMBOL(), but that seems wasteful from a memory foot-print > > look. > > A third option was to put in /lib, but that doesn't seem right - this > > 'find_ibft' code is specific to this module. > > > > Of all the options, the cleanest looks to be the first choice :-( > > (I am not trying to be obstinate here - I just can't think of any > > other reasonable place). > > If you insist on putting it in a .h file, it needs to be marked "inline" > at the least. Ok. > But, why not just put it in a separate file, that is built in if the > user wants iscsi support? That way the setup code can call it properly > if needed. In what directory should I put that file? It can't be in the arch/* directories b/c the iscsi_ibft.c wouldn't build on all platforms. Should I put it in drivers/firmware ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
On Tue, Nov 27, 2007 at 11:09:19AM -0800, Greg KH wrote:
> On Tue, Nov 27, 2007 at 02:09:50PM -0400, [EMAIL PROTECTED] wrote:
> > On Mon, Nov 26, 2007 at 09:29:55PM -0800, Greg KH wrote:
> > > On Mon, Nov 26, 2007 at 11:23:31PM -0500, Konrad Rzeszutek wrote:
> > > > On Monday 26 November 2007 22:31:38 Greg KH wrote:
> > > > > > +#if defined(CONFIG_ISCSI_IBFT) || defined(CONFIG_ISCSI_IBFT_MODULE)
> > > > ..snip..
> > > > > > +static ssize_t find_ibft(void)
> > > > > > +{
> > > > ..snip..
> > > > > > +}
> > > > >
> > > > > What is a function (not even an inline one) doing in a .h file?
> > > >
> > > > I was not sure where to put it. This function (find_ibft) is used by
> > > > the
> > > > setup_[32|64].c and the iscsi_ibft.c code. Randy suggested I put in .c
> > > > file,
> > > > but I am not sure exactly where? Should I make a new file in called
> > > > libs/iscsi_ibft_helper.c ?
> > >
> > > Put it in your .c file and make it a global function to be called by
> > > someone else if they need it.
> >
> > If the kernel is built with CONFIG_ISCSI_IBFT=m, the
> > setup_[32|64],c code would depend on the 'find_ibft' symbol which is
> > in a module (in the iscsi_ibft.c), which is not available during
> > the bootup phase and not linked to vmlinuz.
>
> Ah, then don't allow that :)
>
> > This isn't an issue if the module is built with CONFIG_ISCSI_IBFT=y of
> > course.
> >
> > Or did by 'your .c file' mean a new file in arch/x86/kernel directory?
>
> I didn't realize an external file, outside of your changes, needed this
> function. If it does, then perhaps you need to just place it elsewhere.
The fundamental problem is that 'find_ibft' ought to be available
from anywhere (or at least from the iscsi_ibft.c) so that the iscsi_ibft
module can be loaded on any platform. But on x86, it needs to be called
from setup_[32|64].c because the IBFT can be located anywhere
between 512KB and 1MB - and the E820 does not neccesarily have to
exclude that region. Hence the patch I proposed implements a
'reserve_ibft_region' code which would reserve the region of memory
found by 'find_ibft' so that it can be preserved when iscsi_ibft
module is actually loaded.
It ends up that there are three consumers of 'find_ibft':
a) the module itself (iscsi_ibft.c)
b) setup_32.c
c) setup_64.c
The first choice, which looked the most flexible, was to have it
in iscsi_ibft.h file.
The second one, which would inhibit the user from making iscsi_ibft
a module, would be to move it to iscsi_ibft.c and make it
EXPORT_SYMBOL(), but that seems wasteful from a memory foot-print
look.
A third option was to put in /lib, but that doesn't seem right - this
'find_ibft' code is specific to this module.
Of all the options, the cleanest looks to be the first choice :-(
(I am not trying to be obstinate here - I just can't think of any
other reasonable place).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
On Tue, Nov 27, 2007 at 11:09:19AM -0800, Greg KH wrote:
On Tue, Nov 27, 2007 at 02:09:50PM -0400, [EMAIL PROTECTED] wrote:
On Mon, Nov 26, 2007 at 09:29:55PM -0800, Greg KH wrote:
On Mon, Nov 26, 2007 at 11:23:31PM -0500, Konrad Rzeszutek wrote:
On Monday 26 November 2007 22:31:38 Greg KH wrote:
+#if defined(CONFIG_ISCSI_IBFT) || defined(CONFIG_ISCSI_IBFT_MODULE)
..snip..
+static ssize_t find_ibft(void)
+{
..snip..
+}
What is a function (not even an inline one) doing in a .h file?
I was not sure where to put it. This function (find_ibft) is used by
the
setup_[32|64].c and the iscsi_ibft.c code. Randy suggested I put in .c
file,
but I am not sure exactly where? Should I make a new file in called
libs/iscsi_ibft_helper.c ?
Put it in your .c file and make it a global function to be called by
someone else if they need it.
If the kernel is built with CONFIG_ISCSI_IBFT=m, the
setup_[32|64],c code would depend on the 'find_ibft' symbol which is
in a module (in the iscsi_ibft.c), which is not available during
the bootup phase and not linked to vmlinuz.
Ah, then don't allow that :)
This isn't an issue if the module is built with CONFIG_ISCSI_IBFT=y of
course.
Or did by 'your .c file' mean a new file in arch/x86/kernel directory?
I didn't realize an external file, outside of your changes, needed this
function. If it does, then perhaps you need to just place it elsewhere.
The fundamental problem is that 'find_ibft' ought to be available
from anywhere (or at least from the iscsi_ibft.c) so that the iscsi_ibft
module can be loaded on any platform. But on x86, it needs to be called
from setup_[32|64].c because the IBFT can be located anywhere
between 512KB and 1MB - and the E820 does not neccesarily have to
exclude that region. Hence the patch I proposed implements a
'reserve_ibft_region' code which would reserve the region of memory
found by 'find_ibft' so that it can be preserved when iscsi_ibft
module is actually loaded.
It ends up that there are three consumers of 'find_ibft':
a) the module itself (iscsi_ibft.c)
b) setup_32.c
c) setup_64.c
The first choice, which looked the most flexible, was to have it
in iscsi_ibft.h file.
The second one, which would inhibit the user from making iscsi_ibft
a module, would be to move it to iscsi_ibft.c and make it
EXPORT_SYMBOL(), but that seems wasteful from a memory foot-print
look.
A third option was to put in /lib, but that doesn't seem right - this
'find_ibft' code is specific to this module.
Of all the options, the cleanest looks to be the first choice :-(
(I am not trying to be obstinate here - I just can't think of any
other reasonable place).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
I didn't realize an external file, outside of your changes, needed this function. If it does, then perhaps you need to just place it elsewhere. The fundamental problem is that 'find_ibft' ought to be available from anywhere (or at least from the iscsi_ibft.c) so that the iscsi_ibft module can be loaded on any platform. But on x86, it needs to be called from setup_[32|64].c because the IBFT can be located anywhere between 512KB and 1MB - and the E820 does not neccesarily have to exclude that region. Hence the patch I proposed implements a 'reserve_ibft_region' code which would reserve the region of memory found by 'find_ibft' so that it can be preserved when iscsi_ibft module is actually loaded. It ends up that there are three consumers of 'find_ibft': a) the module itself (iscsi_ibft.c) b) setup_32.c c) setup_64.c The first choice, which looked the most flexible, was to have it in iscsi_ibft.h file. The second one, which would inhibit the user from making iscsi_ibft a module, would be to move it to iscsi_ibft.c and make it EXPORT_SYMBOL(), but that seems wasteful from a memory foot-print look. A third option was to put in /lib, but that doesn't seem right - this 'find_ibft' code is specific to this module. Of all the options, the cleanest looks to be the first choice :-( (I am not trying to be obstinate here - I just can't think of any other reasonable place). If you insist on putting it in a .h file, it needs to be marked inline at the least. Ok. But, why not just put it in a separate file, that is built in if the user wants iscsi support? That way the setup code can call it properly if needed. In what directory should I put that file? It can't be in the arch/* directories b/c the iscsi_ibft.c wouldn't build on all platforms. Should I put it in drivers/firmware ? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
On Mon, Nov 26, 2007 at 09:29:55PM -0800, Greg KH wrote:
> On Mon, Nov 26, 2007 at 11:23:31PM -0500, Konrad Rzeszutek wrote:
> > On Monday 26 November 2007 22:31:38 Greg KH wrote:
> > > > +#if defined(CONFIG_ISCSI_IBFT) || defined(CONFIG_ISCSI_IBFT_MODULE)
> > ..snip..
> > > > +static ssize_t find_ibft(void)
> > > > +{
> > ..snip..
> > > > +}
> > >
> > > What is a function (not even an inline one) doing in a .h file?
> >
> > I was not sure where to put it. This function (find_ibft) is used by the
> > setup_[32|64].c and the iscsi_ibft.c code. Randy suggested I put in .c
> > file,
> > but I am not sure exactly where? Should I make a new file in called
> > libs/iscsi_ibft_helper.c ?
>
> Put it in your .c file and make it a global function to be called by
> someone else if they need it.
If the kernel is built with CONFIG_ISCSI_IBFT=m, the
setup_[32|64],c code would depend on the 'find_ibft' symbol which is
in a module (in the iscsi_ibft.c), which is not available during
the bootup phase and not linked to vmlinuz.
This isn't an issue if the module is built with CONFIG_ISCSI_IBFT=y of
course.
Or did by 'your .c file' mean a new file in arch/x86/kernel directory?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
On Mon, Nov 26, 2007 at 09:29:55PM -0800, Greg KH wrote:
On Mon, Nov 26, 2007 at 11:23:31PM -0500, Konrad Rzeszutek wrote:
On Monday 26 November 2007 22:31:38 Greg KH wrote:
+#if defined(CONFIG_ISCSI_IBFT) || defined(CONFIG_ISCSI_IBFT_MODULE)
..snip..
+static ssize_t find_ibft(void)
+{
..snip..
+}
What is a function (not even an inline one) doing in a .h file?
I was not sure where to put it. This function (find_ibft) is used by the
setup_[32|64].c and the iscsi_ibft.c code. Randy suggested I put in .c
file,
but I am not sure exactly where? Should I make a new file in called
libs/iscsi_ibft_helper.c ?
Put it in your .c file and make it a global function to be called by
someone else if they need it.
If the kernel is built with CONFIG_ISCSI_IBFT=m, the
setup_[32|64],c code would depend on the 'find_ibft' symbol which is
in a module (in the iscsi_ibft.c), which is not available during
the bootup phase and not linked to vmlinuz.
This isn't an issue if the module is built with CONFIG_ISCSI_IBFT=y of
course.
Or did by 'your .c file' mean a new file in arch/x86/kernel directory?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Inhibit NMI watchdog when Alt-SysRq-T operation is underway.
On Mon, Jul 09, 2007 at 10:02:42AM -0400, Konrad Rzeszutek wrote:
> On large memory configuration with not so fast CPUs the NMI watchdog
> is triggered when memory addresses are being gathered and printed.
> The code paths for Alt-SysRq-t are sprinkled with touch_nmi_watchdog
> in various places but not in this routine (or in the loop that utilizes
> this function). The patch has been tested for regression on large CPU+memory
> configuration (128 logical CPUs + 224 GB) and 1,2,4,16-CPU sockets with
> various
> memory sizes (1,2,4,6,20).
And the patch:
diff --git a/arch/x86_64/kernel/traps.c b/arch/x86_64/kernel/traps.c
index aac1c0b..b6e7d67 100644
--- a/arch/x86_64/kernel/traps.c
+++ b/arch/x86_64/kernel/traps.c
@@ -330,6 +330,10 @@ static int print_trace_stack(void *data,
static void print_trace_address(void *data, unsigned long addr)
{
+ static int i = 0;
+ if (i && ((i % 8) == 0))
+ touch_nmi_watchdog();
+ i++;
printk_address(addr);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Inhibit NMI watchdog when Alt-SysRq-T operation is underway.
On Mon, Jul 09, 2007 at 10:02:42AM -0400, Konrad Rzeszutek wrote:
On large memory configuration with not so fast CPUs the NMI watchdog
is triggered when memory addresses are being gathered and printed.
The code paths for Alt-SysRq-t are sprinkled with touch_nmi_watchdog
in various places but not in this routine (or in the loop that utilizes
this function). The patch has been tested for regression on large CPU+memory
configuration (128 logical CPUs + 224 GB) and 1,2,4,16-CPU sockets with
various
memory sizes (1,2,4,6,20).
And the patch:
diff --git a/arch/x86_64/kernel/traps.c b/arch/x86_64/kernel/traps.c
index aac1c0b..b6e7d67 100644
--- a/arch/x86_64/kernel/traps.c
+++ b/arch/x86_64/kernel/traps.c
@@ -330,6 +330,10 @@ static int print_trace_stack(void *data,
static void print_trace_address(void *data, unsigned long addr)
{
+ static int i = 0;
+ if (i ((i % 8) == 0))
+ touch_nmi_watchdog();
+ i++;
printk_address(addr);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
