Re: [patch 1/6] mmu_notifier: Core code
On Fri, 15 Feb 2008 19:37:19 PST, Andrew Morton wrote: > Which other potential clients have been identified and how important it it > to those? The powerpc ehea utilizes its own mmu. Not sure about the importance to the driver. (But will investigate :) ++doug -- 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 1/6] mmu_notifier: Core code
On Fri, 15 Feb 2008 19:37:19 PST, Andrew Morton wrote: Which other potential clients have been identified and how important it it to those? The powerpc ehea utilizes its own mmu. Not sure about the importance to the driver. (But will investigate :) ++doug -- 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.4.5)
On Mon, 28 Jan 2008 14:04:51 EST, Konrad Rzeszutek wrote: > > > +EXPORT_SYMBOL(find_ibft); > > > > Is this x86-specific? Are suitable Kconfig dependencies in place? > > Originally I had it to be x86-specific but was told that I should make it all > platforms since the IBFT is platform independent. Somebody can very well > insert a NIC with IBFT on a IA64 machine or PPC. > I would beg to differ regarding the powerpc. On powerpc, the bios is invisible and ignored. We have our own "special" way, via the device-tree in procfs. ++doug -- 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.4.5)
On Mon, 28 Jan 2008 14:04:51 EST, Konrad Rzeszutek wrote: +EXPORT_SYMBOL(find_ibft); Is this x86-specific? Are suitable Kconfig dependencies in place? Originally I had it to be x86-specific but was told that I should make it all platforms since the IBFT is platform independent. Somebody can very well insert a NIC with IBFT on a IA64 machine or PPC. I would beg to differ regarding the powerpc. On powerpc, the bios is invisible and ignored. We have our own special way, via the device-tree in procfs. ++doug -- 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: [REPOST PATCH] Add iSCSI IBFT support (v0.4)
[added cc: to mikec] On Wed, 05 Dec 2007 16:40:46 -0400, Konrad Rzeszutek wrote: > On Wed, Dec 05, 2007 at 02:26:40PM -0600, Doug Maxey wrote: > > > > On Wed, 05 Dec 2007 13:41:21 -0400, Konrad Rzeszutek wrote: > > > > Is the current include from open-iscsi being duplicated? If not, why > > > > not consolidate in one file? > > > > > > The include files that come from open-iscsi that are in the kernel do > > > not have the iBFT data structures in them - therefore no duplication. > > > > That is strictly true, at least the "in the kernel" part. There is a > > file with the definitions, open-iscsi utils/fwparam_ibft/fwparam_ibft.h > > does have the previous definitons. So what to do? Drop that one? Or > > keep duplicating? > > I would say that utils/fwparam_ibft/fwparam_ibft.h and > utils/fwparam_ibft/fwparam_ibft.c would be dropped once this kernel > patch and the patch to open-iscsi to add fwparam_ibft_subsys.c are > reviewed and hopefully accepted. > Ok. If indeed the userspace tool is going completely away, then there would be just the single instance. Is that the plan? -- 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: [REPOST PATCH] Add iSCSI IBFT support (v0.4)
On Wed, 05 Dec 2007 13:41:21 -0400, Konrad Rzeszutek wrote: > > Is the current include from open-iscsi being duplicated? If not, why > > not consolidate in one file? > > The include files that come from open-iscsi that are in the kernel do > not have the iBFT data structures in them - therefore no duplication. That is strictly true, at least the "in the kernel" part. There is a file with the definitions, open-iscsi utils/fwparam_ibft/fwparam_ibft.h does have the previous definitons. So what to do? Drop that one? Or keep duplicating? ++doug -- 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: [REPOST PATCH] Add iSCSI IBFT support (v0.4)
[added cc: to mikec] On Wed, 05 Dec 2007 16:40:46 -0400, Konrad Rzeszutek wrote: On Wed, Dec 05, 2007 at 02:26:40PM -0600, Doug Maxey wrote: On Wed, 05 Dec 2007 13:41:21 -0400, Konrad Rzeszutek wrote: Is the current include from open-iscsi being duplicated? If not, why not consolidate in one file? The include files that come from open-iscsi that are in the kernel do not have the iBFT data structures in them - therefore no duplication. That is strictly true, at least the in the kernel part. There is a file with the definitions, open-iscsi utils/fwparam_ibft/fwparam_ibft.h does have the previous definitons. So what to do? Drop that one? Or keep duplicating? I would say that utils/fwparam_ibft/fwparam_ibft.h and utils/fwparam_ibft/fwparam_ibft.c would be dropped once this kernel patch and the patch to open-iscsi to add fwparam_ibft_subsys.c are reviewed and hopefully accepted. Ok. If indeed the userspace tool is going completely away, then there would be just the single instance. Is that the plan? -- 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: [REPOST PATCH] Add iSCSI IBFT support (v0.4)
On Wed, 05 Dec 2007 13:41:21 -0400, Konrad Rzeszutek wrote: Is the current include from open-iscsi being duplicated? If not, why not consolidate in one file? The include files that come from open-iscsi that are in the kernel do not have the iBFT data structures in them - therefore no duplication. That is strictly true, at least the in the kernel part. There is a file with the definitions, open-iscsi utils/fwparam_ibft/fwparam_ibft.h does have the previous definitons. So what to do? Drop that one? Or keep duplicating? ++doug -- 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: [REPOST PATCH] Add iSCSI IBFT support (v0.4)
Overall, looks nice. Good work.
comments inline below...
On Tue, 04 Dec 2007 20:44:19 -0400, [EMAIL PROTECTED] wrote:
> 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();
> +
Re: [REPOST PATCH] Add iSCSI IBFT support (v0.4)
Overall, looks nice. Good work.
comments inline below...
On Tue, 04 Dec 2007 20:44:19 -0400, [EMAIL PROTECTED] wrote:
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
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
On Mon, 26 Nov 2007 19:31:38 PST, Greg KH wrote:
> On Mon, Nov 26, 2007 at 06:56:42PM -0400, Konrad Rzeszutek wrote:
> > +/*
> > + * Routines for reading of the iBFT data in a human readable fashion.
> > + */
> > +ssize_t ibft_attr_show_initiator(struct ibft_kobject *entry,
> > +struct ibft_attribute *attr,
> > +char *buf)
> > +{
> > + struct ibft_initiator *initiator = attr->initiator;
> > + void *ibft_loc = entry->data->hdr;
> > + char *str = buf;
> > +
> > + if (!initiator)
> > + return 0;
> > +
> > + str += sprintf_ipaddr(str, "isns", initiator->isns_server);
> > + str += sprintf_ipaddr(str, "slp", initiator->slp_server);
> > + str += sprintf_ipaddr(str, "primary_radius_server",
> > + initiator->pri_radius_server);
> > + str += sprintf_ipaddr(str, "secondary_radius_server",
> > + initiator->sec_radius_server);
> > + str += sprintf_string(str, "itname", initiator->initiator_name_len,
> > + (char *)ibft_loc + initiator->initiator_name_off);
> > + str--;
> > +
> > + return str-buf;
> > +}
>
> sysfs files have ONE VALUE PER FILE, not a whole bunch of different
> things in a single file. Please fix this.
The subparameters _are_ actually part of a single value, that value being
associated with the initiator instance.
Konrad is trying to implement a "work-alike" for what open firmware does.
open-iscsi already has the ability to extract the same format
bits from real OFW.
See open-iscsi.git/utils/fwparam_ppc.
>
>
> > +
> > +ssize_t ibft_attr_show_nic(struct ibft_kobject *entry,
> > + struct ibft_attribute *attr,
> > + char *buf)
> > +{
> > + struct ibft_nic *nic = attr->nic;
> > + void *ibft_loc = entry->data->hdr;
> > + char *str = buf;
> > +
> > + if (!nic)
> > + return 0;
> > + /*
> > +* Assume dhcp if any non-zero portions of its address are set.
> > +*/
> > + if (memcmp(nic->dhcp, nulls, sizeof(nic->dhcp))) {
> > + str += sprintf_ipaddr(str, "dhcp", nic->dhcp);
> > + } else {
> > + str += sprintf_ipaddr(str, "ciaddr", nic->ip_addr);
> > + str += sprintf_ipaddr(str, "giaddr", nic->gateway);
> > + str += sprintf_ipaddr(str, "dnsaddr1", nic->primary_dns);
> > + str += sprintf_ipaddr(str, "dnsaddr2", nic->secondary_dns);
> > + }
> > + if (nic->hostname_len)
> > + str += sprintf_string(str, "hostname", nic->hostname_len,
> > + (char *)ibft_loc + nic->hostname_off);
> > + /* Cut off the comma. */
> > + str--;
> > +
> > + return str-buf;
> > +}
>
> Same here.
>
> > +ssize_t ibft_attr_show_target(struct ibft_kobject *entry,
> > + struct ibft_attribute *attr,
> > + char *buf)
> > +{
> > + struct ibft_tgt *tgt = attr->tgt;
> > + void *ibft_loc = entry->data->hdr;
> > + char *str = buf;
> > + int i;
> > +
> > + if (!tgt)
> > + return 0;
> > +
> > + str += sprintf_ipaddr(str, "siaddr", tgt->ip_addr);
> > + str += sprintf(str, "iport=%d,", tgt->port);
> > + str += sprintf(str, "ilun=");
> > + for (i = 0; i < 8; i++)
> > + str += sprintf(str, "%x", (u8)tgt->lun[i]);
> > + str += sprintf(str, ",");
> > +
> > + if (tgt->tgt_name_len)
> > + str += sprintf_string(str, "iname", tgt->tgt_name_len,
> > + (void *)ibft_loc + tgt->tgt_name_off);
> > +
> > + if (tgt->chap_name_len)
> > + str += sprintf_string(str, "chapid", tgt->chap_name_len,
> > + (char *)ibft_loc + tgt->chap_name_off);
> > + if (tgt->chap_secret_len)
> > + str += sprintf_string(str, "chappw", tgt->chap_secret_len,
> > + (char *)ibft_loc + tgt->chap_secret_off);
> > + if (tgt->rev_chap_name_len)
> > + str += sprintf_string(str, "ichapid", tgt->rev_chap_name_len,
> > + (char *)ibft_loc + tgt->rev_chap_name_off);
> > + if (tgt->rev_chap_secret_len)
> > + str += sprintf_string(str, "ichappw", tgt->rev_chap_secret_len,
> > + (char *)ibft_loc + tgt->rev_chap_secret_off);
> > +
> > + /* Cut off the comma. */
> > + str--;
> > +
> > + return str-buf;
> > +}
>
> Same here, are we writing a novella or something to userspace? :)
Yep. Just like real OFW.
>
> > +ssize_t ibft_attr_show_disk(struct ibft_kobject *dev,
> > + struct ibft_attribute *ibft_attr,
> > + char *buf)
> > +{
> > + char *str = buf;
> > +
> > + str += sprintf(str, "//[EMAIL PROTECTED],%d:iscsi,", dev->data->index);
> > + str += ibft_attr_show_initiator(dev, ibft_attr, str);
> > + str += sprintf(str, ",");
> > + str += ibft_attr_show_target(dev, ibft_attr, str);
> > + str += sprintf(str, ",");
> > + str += ibft_attr_show_nic(dev, ibft_attr, str);
> > +
> > + return str-buf;
> > +}
>
> And here, do I need to go
Re: [PATCH] Add iSCSI IBFT Support (v0.3)
On Mon, 26 Nov 2007 19:31:38 PST, Greg KH wrote:
On Mon, Nov 26, 2007 at 06:56:42PM -0400, Konrad Rzeszutek wrote:
+/*
+ * Routines for reading of the iBFT data in a human readable fashion.
+ */
+ssize_t ibft_attr_show_initiator(struct ibft_kobject *entry,
+struct ibft_attribute *attr,
+char *buf)
+{
+ struct ibft_initiator *initiator = attr-initiator;
+ void *ibft_loc = entry-data-hdr;
+ char *str = buf;
+
+ if (!initiator)
+ return 0;
+
+ str += sprintf_ipaddr(str, isns, initiator-isns_server);
+ str += sprintf_ipaddr(str, slp, initiator-slp_server);
+ str += sprintf_ipaddr(str, primary_radius_server,
+ initiator-pri_radius_server);
+ str += sprintf_ipaddr(str, secondary_radius_server,
+ initiator-sec_radius_server);
+ str += sprintf_string(str, itname, initiator-initiator_name_len,
+ (char *)ibft_loc + initiator-initiator_name_off);
+ str--;
+
+ return str-buf;
+}
sysfs files have ONE VALUE PER FILE, not a whole bunch of different
things in a single file. Please fix this.
The subparameters _are_ actually part of a single value, that value being
associated with the initiator instance.
Konrad is trying to implement a work-alike for what open firmware does.
open-iscsi already has the ability to extract the same format
bits from real OFW.
See open-iscsi.git/utils/fwparam_ppc.
+
+ssize_t ibft_attr_show_nic(struct ibft_kobject *entry,
+ struct ibft_attribute *attr,
+ char *buf)
+{
+ struct ibft_nic *nic = attr-nic;
+ void *ibft_loc = entry-data-hdr;
+ char *str = buf;
+
+ if (!nic)
+ return 0;
+ /*
+* Assume dhcp if any non-zero portions of its address are set.
+*/
+ if (memcmp(nic-dhcp, nulls, sizeof(nic-dhcp))) {
+ str += sprintf_ipaddr(str, dhcp, nic-dhcp);
+ } else {
+ str += sprintf_ipaddr(str, ciaddr, nic-ip_addr);
+ str += sprintf_ipaddr(str, giaddr, nic-gateway);
+ str += sprintf_ipaddr(str, dnsaddr1, nic-primary_dns);
+ str += sprintf_ipaddr(str, dnsaddr2, nic-secondary_dns);
+ }
+ if (nic-hostname_len)
+ str += sprintf_string(str, hostname, nic-hostname_len,
+ (char *)ibft_loc + nic-hostname_off);
+ /* Cut off the comma. */
+ str--;
+
+ return str-buf;
+}
Same here.
+ssize_t ibft_attr_show_target(struct ibft_kobject *entry,
+ struct ibft_attribute *attr,
+ char *buf)
+{
+ struct ibft_tgt *tgt = attr-tgt;
+ void *ibft_loc = entry-data-hdr;
+ char *str = buf;
+ int i;
+
+ if (!tgt)
+ return 0;
+
+ str += sprintf_ipaddr(str, siaddr, tgt-ip_addr);
+ str += sprintf(str, iport=%d,, tgt-port);
+ str += sprintf(str, ilun=);
+ for (i = 0; i 8; i++)
+ str += sprintf(str, %x, (u8)tgt-lun[i]);
+ str += sprintf(str, ,);
+
+ if (tgt-tgt_name_len)
+ str += sprintf_string(str, iname, tgt-tgt_name_len,
+ (void *)ibft_loc + tgt-tgt_name_off);
+
+ if (tgt-chap_name_len)
+ str += sprintf_string(str, chapid, tgt-chap_name_len,
+ (char *)ibft_loc + tgt-chap_name_off);
+ if (tgt-chap_secret_len)
+ str += sprintf_string(str, chappw, tgt-chap_secret_len,
+ (char *)ibft_loc + tgt-chap_secret_off);
+ if (tgt-rev_chap_name_len)
+ str += sprintf_string(str, ichapid, tgt-rev_chap_name_len,
+ (char *)ibft_loc + tgt-rev_chap_name_off);
+ if (tgt-rev_chap_secret_len)
+ str += sprintf_string(str, ichappw, tgt-rev_chap_secret_len,
+ (char *)ibft_loc + tgt-rev_chap_secret_off);
+
+ /* Cut off the comma. */
+ str--;
+
+ return str-buf;
+}
Same here, are we writing a novella or something to userspace? :)
Yep. Just like real OFW.
+ssize_t ibft_attr_show_disk(struct ibft_kobject *dev,
+ struct ibft_attribute *ibft_attr,
+ char *buf)
+{
+ char *str = buf;
+
+ str += sprintf(str, //[EMAIL PROTECTED],%d:iscsi,, dev-data-index);
+ str += ibft_attr_show_initiator(dev, ibft_attr, str);
+ str += sprintf(str, ,);
+ str += ibft_attr_show_target(dev, ibft_attr, str);
+ str += sprintf(str, ,);
+ str += ibft_attr_show_nic(dev, ibft_attr, str);
+
+ return str-buf;
+}
And here, do I need to go on?
+ssize_t ibft_attr_show_mac(struct ibft_kobject *entry,
+ struct ibft_attribute *attr,
+ char *buf)
+{
+ struct ibft_nic *nic = attr-nic;
+ int len = 6;
+
+ if (!nic)
+ return 0;
+
+ memcpy(buf, attr-nic-mac, len);
+
+ return len;
+}
Is
Re: [PATCH 0/3] Add disk hotswap support to libata
On Thu, 21 Jul 2005 21:35:24 EDT, Jeff Garzik wrote:
>As soon as I finish SATA ATAPI (this week[end]), I'll take a look at
>this. A quick review of the patches didn't turn up anything terribly
>objectionable, though :)
>
I would like to offer to test when you are ready. Some older and new SATAPI
drives, various chipsets (ICH{5,6}, TX4 on the way). And a SATA analyzer
for anything really odd.
++doug
-
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 0/3] Add disk hotswap support to libata
On Thu, 21 Jul 2005 21:35:24 EDT, Jeff Garzik wrote:
As soon as I finish SATA ATAPI (this week[end]), I'll take a look at
this. A quick review of the patches didn't turn up anything terribly
objectionable, though :)
I would like to offer to test when you are ready. Some older and new SATAPI
drives, various chipsets (ICH{5,6}, TX4 on the way). And a SATA analyzer
for anything really odd.
++doug
-
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: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
On Fri, 08 Jul 2005 21:13:26 +0200, Ingo Molnar wrote: > >* K.R. Foley <[EMAIL PROTECTED]> wrote: > >> Ingo, >> >> I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when >> running the RT patches. The problem manifests itself as if the key >> were stuck but happens far too quickly for that to be the case. I >> realize that the statements above are far from scientific, but I can't >> seem to narrow it down further. 2.6.12 doesn't seem to have the >> problem at all, only when running the RT patches. It SEEMS to have >> gotten worse lately. I am attaching my config as well as the output >> from lspci. >> >> Adjusting the delay in the keyboard repeat seems to help. Any ideas? Is the keyboard standard (PS2) or USB? Did not see the detail. > >hm. Would be nice to somehow find a condition that triggers it. One >possibility is that something else is starving the keyboard handling >path. Right now it's handled via workqueues, which live in keventd. Do >things improve if you chrt keventd up to prio 99? Also i'd chrt the >keyboard IRQ thread up to prio 99 too. > >the other possibility is some IRQ handling bug - those are usually >specific to the IRQ controller, so try turning off (or on) the IO-APIC >[if the box has an IO-APIC], does that change anything? FWIW, I have seen this issue under USB, off and on since about 2.6.9. Never have dug into it, was always simpler to just unplug and re-plug the keyboard. Of course, this predates RT. ++doug - 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: Real-Time Preemption -RT-V0.7.51-17 - Keyboard Problems
On Fri, 08 Jul 2005 21:13:26 +0200, Ingo Molnar wrote: * K.R. Foley [EMAIL PROTECTED] wrote: Ingo, I have an issue with keys VERY SPORADICALLY repeating, SOMETIMES, when running the RT patches. The problem manifests itself as if the key were stuck but happens far too quickly for that to be the case. I realize that the statements above are far from scientific, but I can't seem to narrow it down further. 2.6.12 doesn't seem to have the problem at all, only when running the RT patches. It SEEMS to have gotten worse lately. I am attaching my config as well as the output from lspci. Adjusting the delay in the keyboard repeat seems to help. Any ideas? Is the keyboard standard (PS2) or USB? Did not see the detail. hm. Would be nice to somehow find a condition that triggers it. One possibility is that something else is starving the keyboard handling path. Right now it's handled via workqueues, which live in keventd. Do things improve if you chrt keventd up to prio 99? Also i'd chrt the keyboard IRQ thread up to prio 99 too. the other possibility is some IRQ handling bug - those are usually specific to the IRQ controller, so try turning off (or on) the IO-APIC [if the box has an IO-APIC], does that change anything? FWIW, I have seen this issue under USB, off and on since about 2.6.9. Never have dug into it, was always simpler to just unplug and re-plug the keyboard. Of course, this predates RT. ++doug - 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] scsi/sata write barrier support
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote: >Hi, > >For the longest time, only the old PATA drivers supported barrier writes >with journalled file systems. This patch adds support for the same type >of cache flushing barriers that PATA uses for SCSI, to be utilized with >libata. What, if any mechanism supports changing the underlying write cache? That is, assuming this is common across PATA and SCSI drives, and it is possible to turn the cache off on the IDE drives, would switching the cache underneath require completing the inflight IO? ++doug - 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] scsi/sata write barrier support
On Thu, 27 Jan 2005 13:02:48 +0100, Jens Axboe wrote: Hi, For the longest time, only the old PATA drivers supported barrier writes with journalled file systems. This patch adds support for the same type of cache flushing barriers that PATA uses for SCSI, to be utilized with libata. What, if any mechanism supports changing the underlying write cache? That is, assuming this is common across PATA and SCSI drives, and it is possible to turn the cache off on the IDE drives, would switching the cache underneath require completing the inflight IO? ++doug - 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/
