Re: SATA error initializing Marvell 88SX6081
> When using the sata_mv driver, I can't see my drives. > > The drives are SATA6Gbps. > > The SATA card is a Supermicro AOC-SAT2-MV8 SATA3Gbps card with a Marvell > 88SX6081 chip onboard. Never mind, old kernel. Fixed in 3.7.6. Sorry for the noise. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA error initializing Marvell 88SX6081
When using the sata_mv driver, I can't see my drives. The drives are SATA6Gbps. The SATA card is a Supermicro AOC-SAT2-MV8 SATA3Gbps card with a Marvell 88SX6081 chip onboard. Never mind, old kernel. Fixed in 3.7.6. Sorry for the noise. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BMC on Tyan s2885
Does anyone know if the Tyan Thunder K8W (s2885) has a BMC controller for IPMI management on board? If it does, what do I have to enable in the kernel to use it? Cheers, James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BMC on Tyan s2885
Does anyone know if the Tyan Thunder K8W (s2885) has a BMC controller for IPMI management on board? If it does, what do I have to enable in the kernel to use it? Cheers, James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options
On Sun, 2007-09-09 at 15:46 +0200, Andi Kleen wrote: > Thanks. How about a fix for the other problem (ACPI_NUMA- PM) too? > I don't want to just hard-select it until I understand what happened between 2.6.22.6 and current git to make ACPI selectable without PM. Personally, I think ACPI should be independent of PM anyway (at least as it is displayed and selectable in the user interface. Obviously there may be functional relationships between them). There is a "C" in ACPI, after all, and some of that "C" doesn't really have anything to do with power management. James /\ - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 22:00 -0700, Randy Dunlap wrote: > > For example, you would only need to specify one "select" directive in > > X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system > > would then recursively walk up ACPI_NUMA's dependency hierarchy, turning > > on what it needed. > > That is highly desirable IMO. Not having that is one of the things > that makes using 'select' "evil." > > Have you looked at the code and given any thought to implementing this? > I'd like to take a run at it. The only issue I foresee is what to do about multiple OR dependencies. There are some kconfig options that depend on at least one of a set of specified dependencies. For example, is ARCH_SPARSEMEM_ENABLE selectable if only one of NUMA || EXPERIMENTAL is selected? So do we abort, select one, or select all dependencies? Maybe I'm misunderstanding the usage of || here though. I'm assuming inclusive OR. James /\V - 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/
[PATCH] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options
On Sun, 2007-09-09 at 11:07 +0200, Andi Kleen wrote: > "James C. Georgas" <[EMAIL PROTECTED]> writes: > > > > It's 2.6.22.6. I'm thinking a fix would be to add "select PM" to > > X86_64_ACPI_NUMA. > > > > I'm also thinking that maybe K8_NUMA should be changed from "depends on > > PCI" to "select PCI", like X86_64_ACPI_NUMA is. That would fix the > > pseudo dependency they have between them (i.e. selecting > > X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA > > visible, because its PCI dependency is now satisfied). > > Sounds reasonable. Can you please submit a tested patch with proper > description and Signed-off-by lines? > > -Andi How's this? >From 6febbd64aaca5d54487d8f9df4949001e0fc4ec6 Mon Sep 17 00:00:00 2001 From: James C. Georgas <[EMAIL PROTECTED]> Date: Sun, 9 Sep 2007 08:27:46 -0400 Subject: [PATCH] Signed-off-by: James C. Georgas <[EMAIL PROTECTED]> Changed K8_NUMA from "depends on PCI" to "select PCI", like X86_64_ACPI_NUMA is. This fixes the pseudo dependency between X86_64_ACPI_NUMA and K8_NUMA (i.e. selecting X86_64_ACPI_NUMA would cause PCI to be selected, which then made K8_NUMA visible, because its PCI dependency was now satisfied). --- arch/x86_64/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index ffa0364..bdeeb25 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -357,7 +357,8 @@ config NUMA config K8_NUMA bool "Old style AMD Opteron NUMA detection" - depends on NUMA && PCI + depends on NUMA + select PCI default y help Enable K8 NUMA node topology detection. You should say Y here if -- 1.5.1.6 - 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/
[PATCH] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options
On Sun, 2007-09-09 at 11:07 +0200, Andi Kleen wrote: James C. Georgas [EMAIL PROTECTED] writes: It's 2.6.22.6. I'm thinking a fix would be to add select PM to X86_64_ACPI_NUMA. I'm also thinking that maybe K8_NUMA should be changed from depends on PCI to select PCI, like X86_64_ACPI_NUMA is. That would fix the pseudo dependency they have between them (i.e. selecting X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA visible, because its PCI dependency is now satisfied). Sounds reasonable. Can you please submit a tested patch with proper description and Signed-off-by lines? -Andi How's this? From 6febbd64aaca5d54487d8f9df4949001e0fc4ec6 Mon Sep 17 00:00:00 2001 From: James C. Georgas [EMAIL PROTECTED] Date: Sun, 9 Sep 2007 08:27:46 -0400 Subject: [PATCH] Signed-off-by: James C. Georgas [EMAIL PROTECTED] Changed K8_NUMA from depends on PCI to select PCI, like X86_64_ACPI_NUMA is. This fixes the pseudo dependency between X86_64_ACPI_NUMA and K8_NUMA (i.e. selecting X86_64_ACPI_NUMA would cause PCI to be selected, which then made K8_NUMA visible, because its PCI dependency was now satisfied). --- arch/x86_64/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig index ffa0364..bdeeb25 100644 --- a/arch/x86_64/Kconfig +++ b/arch/x86_64/Kconfig @@ -357,7 +357,8 @@ config NUMA config K8_NUMA bool Old style AMD Opteron NUMA detection - depends on NUMA PCI + depends on NUMA + select PCI default y help Enable K8 NUMA node topology detection. You should say Y here if -- 1.5.1.6 - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 22:00 -0700, Randy Dunlap wrote: For example, you would only need to specify one select directive in X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system would then recursively walk up ACPI_NUMA's dependency hierarchy, turning on what it needed. That is highly desirable IMO. Not having that is one of the things that makes using 'select' evil. Have you looked at the code and given any thought to implementing this? I'd like to take a run at it. The only issue I foresee is what to do about multiple OR dependencies. There are some kconfig options that depend on at least one of a set of specified dependencies. For example, is ARCH_SPARSEMEM_ENABLE selectable if only one of NUMA || EXPERIMENTAL is selected? So do we abort, select one, or select all dependencies? Maybe I'm misunderstanding the usage of || here though. I'm assuming inclusive OR. James /\V - 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] KCONFIG: fix pseudo dependency between K8_NUMA and X86_64_ACPI_NUMA config options
On Sun, 2007-09-09 at 15:46 +0200, Andi Kleen wrote: Thanks. How about a fix for the other problem (ACPI_NUMA- PM) too? I don't want to just hard-select it until I understand what happened between 2.6.22.6 and current git to make ACPI selectable without PM. Personally, I think ACPI should be independent of PM anyway (at least as it is displayed and selectable in the user interface. Obviously there may be functional relationships between them). There is a C in ACPI, after all, and some of that C doesn't really have anything to do with power management. James /\ - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote: > 2.6.23-rc5-git1 builds for me when I follow those steps... > except for some Section mismatch warnings. > OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour of the "select" directive in Kconfig appears to have changed since 2.6.22.6. It now turns on ACPI, even when PM is not selected. This still looks broken to me, because ACPI gets selected by ACPI_NUMA, and ACPI depends on PM, but PM is not selected. It works out in the end, as far as the build is concerned, but it still bugs me. Does anyone object to the idea of a selected item automatically selecting its own dependencies? For example, you would only need to specify one "select" directive in X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system would then recursively walk up ACPI_NUMA's dependency hierarchy, turning on what it needed. James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote: > On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote: > > > On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote: > > > > > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected > > > automatically, but ACPI is not selected automatically. This causes > > > ACPI_NUMA to not be built, and the kernel compile fails with unresolved > > > symbols. > > > > exactly what kernel version?? > > > > 2.6.23-rc5-git1 builds for me when I follow those steps... > except for some Section mismatch warnings. What is the git project path name for the 2.6.23rc branch, if I wanted to clone it, to keep up to date? James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:09 -0700, Randy Dunlap wrote: > On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote: > > > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected > > automatically, but ACPI is not selected automatically. This causes > > ACPI_NUMA to not be built, and the kernel compile fails with unresolved > > symbols. > > exactly what kernel version?? > > It's 2.6.22.6. I'm thinking a fix would be to add "select PM" to X86_64_ACPI_NUMA. I'm also thinking that maybe K8_NUMA should be changed from "depends on PCI" to "select PCI", like X86_64_ACPI_NUMA is. That would fix the pseudo dependency they have between them (i.e. selecting X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA visible, because its PCI dependency is now satisfied). James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote: > If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected > automatically, but ACPI is not selected automatically. This causes > ACPI_NUMA to not be built, and the kernel compile fails with unresolved > symbols. > Uh, it seems that I'm getting different results this time. Now, X86_64_ACPI_NUMA does select ACPI, but PM (parent of ACPI) is not automatically selected. Same result for the compile, though. Boom. I seem to get different behaviour in general on subsequent runs of make menuconfig. For example, the last time I ran it, I was able to select K8_NUMA and X86_64_ACPI_NUMA, independently of one another. This time, though, the visibility of K8_NUMA is dependent on whether or not X86_64_ACPI_NUMA is selected. Should K8_NUMA and X86_64_ACPI_NUMA both be under NUMA, and independent of one another? James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote: > Steps to reproduce: > > make clean > make mrproper > make noallconfig Excuse me; that should read allnoconfig, not noallconfig. James /\V - 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/
broken ACPI NUMA config option
If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected automatically, but ACPI is not selected automatically. This causes ACPI_NUMA to not be built, and the kernel compile fails with unresolved symbols. Steps to reproduce: make clean make mrproper make noallconfig select SMP select NUMA select X86_64_ACPI_NUMA make results: LD .tmp_vmlinux1 drivers/built-in.o: In function `acpi_bus_generate_event': (.text+0x23365): undefined reference to `event_is_open' drivers/built-in.o: In function `acpi_bus_get_power': (.text+0x2361d): undefined reference to `acpi_power_get_inferred_state' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x23733): undefined reference to `acpi_power_transition' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x237a5): undefined reference to `acpi_power_transition' make: *** [.tmp_vmlinux1] Error 1 James /\V - 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/
broken ACPI NUMA config option
If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected automatically, but ACPI is not selected automatically. This causes ACPI_NUMA to not be built, and the kernel compile fails with unresolved symbols. Steps to reproduce: make clean make mrproper make noallconfig select SMP select NUMA select X86_64_ACPI_NUMA make boom results: LD .tmp_vmlinux1 drivers/built-in.o: In function `acpi_bus_generate_event': (.text+0x23365): undefined reference to `event_is_open' drivers/built-in.o: In function `acpi_bus_get_power': (.text+0x2361d): undefined reference to `acpi_power_get_inferred_state' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x23733): undefined reference to `acpi_power_transition' drivers/built-in.o: In function `acpi_bus_set_power': (.text+0x237a5): undefined reference to `acpi_power_transition' make: *** [.tmp_vmlinux1] Error 1 James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote: Steps to reproduce: make clean make mrproper make noallconfig Excuse me; that should read allnoconfig, not noallconfig. James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:51 -0400, James C. Georgas wrote: If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected automatically, but ACPI is not selected automatically. This causes ACPI_NUMA to not be built, and the kernel compile fails with unresolved symbols. Uh, it seems that I'm getting different results this time. Now, X86_64_ACPI_NUMA does select ACPI, but PM (parent of ACPI) is not automatically selected. Same result for the compile, though. Boom. I seem to get different behaviour in general on subsequent runs of make menuconfig. For example, the last time I ran it, I was able to select K8_NUMA and X86_64_ACPI_NUMA, independently of one another. This time, though, the visibility of K8_NUMA is dependent on whether or not X86_64_ACPI_NUMA is selected. Should K8_NUMA and X86_64_ACPI_NUMA both be under NUMA, and independent of one another? James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:09 -0700, Randy Dunlap wrote: On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote: If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected automatically, but ACPI is not selected automatically. This causes ACPI_NUMA to not be built, and the kernel compile fails with unresolved symbols. exactly what kernel version?? It's 2.6.22.6. I'm thinking a fix would be to add select PM to X86_64_ACPI_NUMA. I'm also thinking that maybe K8_NUMA should be changed from depends on PCI to select PCI, like X86_64_ACPI_NUMA is. That would fix the pseudo dependency they have between them (i.e. selecting X86_64_ACPI_NUMA causes PCI to be selected, which then makes K8_NUMA visible, because its PCI dependency is now satisfied). James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote: On Sat, 8 Sep 2007 18:09:04 -0700 Randy Dunlap wrote: On Sat, 08 Sep 2007 18:51:39 -0400 James C. Georgas wrote: If I select X86_64_ACPI_NUMA, then ACPI_NUMA is (properly) selected automatically, but ACPI is not selected automatically. This causes ACPI_NUMA to not be built, and the kernel compile fails with unresolved symbols. exactly what kernel version?? 2.6.23-rc5-git1 builds for me when I follow those steps... except for some Section mismatch warnings. What is the git project path name for the 2.6.23rc branch, if I wanted to clone it, to keep up to date? James /\V - 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: broken ACPI NUMA config option
On Sat, 2007-08-09 at 18:16 -0700, Randy Dunlap wrote: 2.6.23-rc5-git1 builds for me when I follow those steps... except for some Section mismatch warnings. OK, it worked for me also, using torvalds/linux-2.6.git. The behaviour of the select directive in Kconfig appears to have changed since 2.6.22.6. It now turns on ACPI, even when PM is not selected. This still looks broken to me, because ACPI gets selected by ACPI_NUMA, and ACPI depends on PM, but PM is not selected. It works out in the end, as far as the build is concerned, but it still bugs me. Does anyone object to the idea of a selected item automatically selecting its own dependencies? For example, you would only need to specify one select directive in X86_64_ACPI_NUMA, (i.e. to turn on ACPI_NUMA). The configuration system would then recursively walk up ACPI_NUMA's dependency hierarchy, turning on what it needed. James /\V - 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/
HIMEM calculation
I'm not sure I understand how the kernel calculates the amount of physical RAM it can map during the boot process. I've quoted two blocks of kernel messages below, one for a kernel with NOHIGHMEM and another for a kernel with HIGHMEM4G. If I do the math on the BIOS provided physical RAM map, there is less than 5MiB of the address space reserved. Since I only have 1GiB of physical RAM in the board, I figured that it would still be possible to physically map 1019MiB, even with the 3GiB/1GiB split between user space and kernel space that occurs with NOHIGHMEM. However, What actually happens is that I'm 127MiB short of a full GiB. What am I missing here? Why does that last 127MiB have to go in HIGHMEM? Message log for a NOHIGHMEM kernel: Sep 3 16:56:50 Tachyon kernel: Linux version 2.6.22-gentoo-r5 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #2 PREEMPT Mon Sep 3 16:01:08 EDT 2007 Sep 3 16:56:50 Tachyon kernel: BIOS-provided physical RAM map: Sep 3 16:56:50 Tachyon kernel: BIOS-e820: - 0009fc00 (usable) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 0009fc00 - 000a (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 0010 - 3ffd3000 (usable) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 3ffd3000 - 4000 (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: feda - fee0 (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: ffb8 - 0001 (reserved) Sep 3 16:56:50 Tachyon kernel: Warning only 896MB will be used. Sep 3 16:56:50 Tachyon kernel: Use a HIGHMEM enabled kernel. Sep 3 16:56:50 Tachyon kernel: 896MB LOWMEM available. Sep 3 16:56:50 Tachyon kernel: Zone PFN ranges: Sep 3 16:56:50 Tachyon kernel: DMA 0 -> 4096 Sep 3 16:56:50 Tachyon kernel: Normal 4096 -> 229376 Sep 3 16:56:50 Tachyon kernel: early_node_map[1] active PFN ranges Sep 3 16:56:50 Tachyon kernel: 0:0 -> 229376 Sep 3 16:56:50 Tachyon kernel: DMI 2.3 present. Message log for a HIGHMEM4G kernel: Sep 3 17:40:53 Tachyon kernel: BIOS-provided physical RAM map: Sep 3 17:40:53 Tachyon kernel: BIOS-e820: - 0009fc00 (usable) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 0009fc00 - 000a (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 0010 - 3ffd3000 (usable) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 3ffd3000 - 4000 (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: feda - fee0 (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: ffb8 - 0001 (reserved) Sep 3 17:40:53 Tachyon kernel: 127MB HIGHMEM available. Sep 3 17:40:53 Tachyon kernel: 896MB LOWMEM available. Sep 3 17:40:53 Tachyon kernel: Zone PFN ranges: Sep 3 17:40:53 Tachyon kernel: DMA 0 -> 4096 Sep 3 17:40:53 Tachyon kernel: Normal 4096 -> 229376 Sep 3 17:40:53 Tachyon kernel: HighMem229376 -> 262099 Sep 3 17:40:53 Tachyon kernel: early_node_map[1] active PFN ranges Sep 3 17:40:53 Tachyon kernel: 0:0 -> 262099 Sep 3 17:40:53 Tachyon kernel: DMI 2.3 present. - 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/
HIMEM calculation
I'm not sure I understand how the kernel calculates the amount of physical RAM it can map during the boot process. I've quoted two blocks of kernel messages below, one for a kernel with NOHIGHMEM and another for a kernel with HIGHMEM4G. If I do the math on the BIOS provided physical RAM map, there is less than 5MiB of the address space reserved. Since I only have 1GiB of physical RAM in the board, I figured that it would still be possible to physically map 1019MiB, even with the 3GiB/1GiB split between user space and kernel space that occurs with NOHIGHMEM. However, What actually happens is that I'm 127MiB short of a full GiB. What am I missing here? Why does that last 127MiB have to go in HIGHMEM? Message log for a NOHIGHMEM kernel: Sep 3 16:56:50 Tachyon kernel: Linux version 2.6.22-gentoo-r5 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #2 PREEMPT Mon Sep 3 16:01:08 EDT 2007 Sep 3 16:56:50 Tachyon kernel: BIOS-provided physical RAM map: Sep 3 16:56:50 Tachyon kernel: BIOS-e820: - 0009fc00 (usable) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 0009fc00 - 000a (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 0010 - 3ffd3000 (usable) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: 3ffd3000 - 4000 (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: feda - fee0 (reserved) Sep 3 16:56:50 Tachyon kernel: BIOS-e820: ffb8 - 0001 (reserved) Sep 3 16:56:50 Tachyon kernel: Warning only 896MB will be used. Sep 3 16:56:50 Tachyon kernel: Use a HIGHMEM enabled kernel. Sep 3 16:56:50 Tachyon kernel: 896MB LOWMEM available. Sep 3 16:56:50 Tachyon kernel: Zone PFN ranges: Sep 3 16:56:50 Tachyon kernel: DMA 0 - 4096 Sep 3 16:56:50 Tachyon kernel: Normal 4096 - 229376 Sep 3 16:56:50 Tachyon kernel: early_node_map[1] active PFN ranges Sep 3 16:56:50 Tachyon kernel: 0:0 - 229376 Sep 3 16:56:50 Tachyon kernel: DMI 2.3 present. Message log for a HIGHMEM4G kernel: Sep 3 17:40:53 Tachyon kernel: BIOS-provided physical RAM map: Sep 3 17:40:53 Tachyon kernel: BIOS-e820: - 0009fc00 (usable) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 0009fc00 - 000a (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 0010 - 3ffd3000 (usable) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: 3ffd3000 - 4000 (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: feda - fee0 (reserved) Sep 3 17:40:53 Tachyon kernel: BIOS-e820: ffb8 - 0001 (reserved) Sep 3 17:40:53 Tachyon kernel: 127MB HIGHMEM available. Sep 3 17:40:53 Tachyon kernel: 896MB LOWMEM available. Sep 3 17:40:53 Tachyon kernel: Zone PFN ranges: Sep 3 17:40:53 Tachyon kernel: DMA 0 - 4096 Sep 3 17:40:53 Tachyon kernel: Normal 4096 - 229376 Sep 3 17:40:53 Tachyon kernel: HighMem229376 - 262099 Sep 3 17:40:53 Tachyon kernel: early_node_map[1] active PFN ranges Sep 3 17:40:53 Tachyon kernel: 0:0 - 262099 Sep 3 17:40:53 Tachyon kernel: DMI 2.3 present. - 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: Binary Drivers
On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote: > On 12/25/06, David Schwartz <[EMAIL PROTECTED]> wrote: > > > If I bought the car from the manufacturer, it also must > > include any rights the manufacturer might have to the car's use. > > That includes using the car to violate emission control measures. > > If I didn't buy the right to use the car that way (insofar as > > that right was owned by the car manufacturer), I didn't > > buy the whole care -- just *some* of the rights to use it. > > just to be dense - what makes you think that the car manufacturer has > any legal right to violate emission control measures? What an utter > nonsense (sorry). > > So, lets stop the stupid car comparisons. They are no being funny any > more. Let's summarize the current situation: 1) Hardware vendors don't have to tell us how to program their products, as long as they provide some way to use it (i.e. binary blob driver). 2) Hardware vendors don't want to tell us how to program their products, because they think this information is their secret sauce (or maybe their competitor's secret sauce). 3) Hardware vendors don't tell us how to program their products, because they know about (1) and they believe (2). 4) We need products with datasheets because of our development model. 5) We want products with capabilities that these vendors advertise. 6) Products that satisfy both (4) and (5) are often scarce or non-existent. So far, the suggestions I've seen to resolve the above conflict fall into three categories: a) Force vendors to provide datasheets. b) Entice vendors to provide datasheets. c) Reverse engineer the hardware and write our own datasheets. Solution (a) involves denial of point (1), mostly through the use of analogy and allegory. Alternatively, one can try to change the law through government channels. Solution (b) requires market pressure, charity, or visionary management. We can't exert enough market pressure currently to make much difference. Charity sometimes gives us datasheets for old hardware. Visionary management is the future. Solution (c) is what we do now, with varying degrees of success. A good example is the R300 support in the radeon DRM module. Did I miss anything? - 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: Binary Drivers
On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote: On 12/25/06, David Schwartz [EMAIL PROTECTED] wrote: If I bought the car from the manufacturer, it also must include any rights the manufacturer might have to the car's use. That includes using the car to violate emission control measures. If I didn't buy the right to use the car that way (insofar as that right was owned by the car manufacturer), I didn't buy the whole care -- just *some* of the rights to use it. just to be dense - what makes you think that the car manufacturer has any legal right to violate emission control measures? What an utter nonsense (sorry). So, lets stop the stupid car comparisons. They are no being funny any more. Let's summarize the current situation: 1) Hardware vendors don't have to tell us how to program their products, as long as they provide some way to use it (i.e. binary blob driver). 2) Hardware vendors don't want to tell us how to program their products, because they think this information is their secret sauce (or maybe their competitor's secret sauce). 3) Hardware vendors don't tell us how to program their products, because they know about (1) and they believe (2). 4) We need products with datasheets because of our development model. 5) We want products with capabilities that these vendors advertise. 6) Products that satisfy both (4) and (5) are often scarce or non-existent. So far, the suggestions I've seen to resolve the above conflict fall into three categories: a) Force vendors to provide datasheets. b) Entice vendors to provide datasheets. c) Reverse engineer the hardware and write our own datasheets. Solution (a) involves denial of point (1), mostly through the use of analogy and allegory. Alternatively, one can try to change the law through government channels. Solution (b) requires market pressure, charity, or visionary management. We can't exert enough market pressure currently to make much difference. Charity sometimes gives us datasheets for old hardware. Visionary management is the future. Solution (c) is what we do now, with varying degrees of success. A good example is the R300 support in the radeon DRM module. Did I miss anything? - 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: Binary Drivers
On Sun, 2006-24-12 at 09:33 -0800, David Schwartz wrote: > > On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said: > > > > You can't sell something that doesn't exist. If you sell a car > > > even though > > > you can't explain how anyone could drive it, that's fraud. > > > Are they allowed to sell a car that incorporates a computer that uses a > > trade-secret algorithm for controlling the fuel injection to get 20 more > > horsepower and 5% better mileage? > > I assume that's a rhetorical question. Of course they are. > > Now, let's try it another way: Are they allowed to sell a car that > incorporates a computer that uses a trade-secret algorithm for controlling > the fuel injection to get 20 more horsepower and 5% better mileage if it's > impossible to *start* the car without knowing that algorithm? > > Then, I think it's obvious the answer is, of course, no. If you buy the car, > they have to tell you the algorithm. > > If knowledge of the algorithm is required to use the car in a reasonable > way, even if it's not the normal expected way, then they can't keep it > secret. They can't sell something while keeping secret how to *use* it. And > that doesn't just mean the normal expected use. Buying something free and > clear allows you to use it even in unusual ways. > > Perhaps that wasn't the best example. Let's try another one. You buy a car, > and then discover that the car computer has a lockout and a code needs to be > entered on the alarm panel to start the car between 4 AM and 4:15 AM on > Tuesdays. You ask the manufacturer for that code, since you would like to > start your car between 4 AM and 4:15 AM on Tuesdays even though many people > don't. > > How many of the following answers would you consider fair: > > 1) We never wrote the code down. We knew it, but we didn't put it in a form > in which we can give it to you. Most people don't need it anyway. Sorry. > > 2) We're sorry. We know the code, but our contract with another company > prohibits us from disclosing it. > > And so on. > > Buying the car includes the right to start it between 4 AM and 4:15 AM on > Tuesdays if that's what you want to do. If the manufacturer couldn't sell > you the right or ability to do that, it couldn't sell you the car. > > Owning a video card includes the right to make it work with Linux if that's > what you want to do. If the manufacturer couldn't sell you the right or > ability to do that, it couldn't sell you the video card. > Here's my personal favourite example: You walk into a car dealership to buy a new car, because your old car is too slow to drive on the freeway; you need something faster. The salesman shows you a great vehicle. He tells you all about how this car is the pinnacle of automotive technology. It's got muscle. It's got finesse. It's got tons of state of the art bells and whistles. Your friends will be s jealous. Chicks will dig you. You have to have it. You pay the man and have it delivered to you house. When it arrives, you can't figure out how to open the door. The front windows are opaque, so you can't see inside. You: "Hey, delivery guy. How do I open the door on this thing?". Guy: "I'm not the delivery guy. I'm your driver." You: "Huh? Look, I don't need a driver, OK? I'll drive it myself. So how do I open the door?" Driver: "I'm sorry sir, but I can't tell you that. It's secret car company stuff. If I told you, then our competition might find out how we do it, and we would lose our competitive advantage." You: "Whatever. I need to get to work. Let's go." You get in the back seat, but there is an opaque barrier between you and the front of the car. Driver: "Just talk into the speaker on your left, sir, and I'll go where you tell me to." You get out on the freeway, but you're only going 30 kph. You: "What the hell is wrong with this thing? I thought this car was the fastest thing on the road. Pick it up, why don't you?" Driver: "I'm sorry sir. I don't really know how to make the car go faster than 30 kph. This is a new model, and the company hasn't yet taught us how to drive it fast. Check in with them next month. They're always training new drivers, and they might have a replacement for you by then." You: "Well that's just great. Let's get off the freeway. Take a left on Broadway, at the bottom of the off-ramp." You exit the freeway, but as you are turning left onto Broadway, your car stalls in the intersection. You: "Hey driver, WTF?" Driver: "Sorry Sir, I seem t0 baeo ++_?+CFY^K$# ekbae." The driver stumbles out of the car and starts spazzing out on the ground. After a couple of minutes he's OK and you get back on the road. There's an uncomfortable silence in the car. You don't tell him to turn left any more. Six months later, the company sends you a replacement driver. Driver2: "Sorry it took so long sir. You see, there's not much call for drivers who know the streets in this
RE: Binary Drivers
On Sun, 2006-24-12 at 09:33 -0800, David Schwartz wrote: On Fri, 22 Dec 2006 23:19:09 PST, David Schwartz said: You can't sell something that doesn't exist. If you sell a car even though you can't explain how anyone could drive it, that's fraud. Are they allowed to sell a car that incorporates a computer that uses a trade-secret algorithm for controlling the fuel injection to get 20 more horsepower and 5% better mileage? I assume that's a rhetorical question. Of course they are. Now, let's try it another way: Are they allowed to sell a car that incorporates a computer that uses a trade-secret algorithm for controlling the fuel injection to get 20 more horsepower and 5% better mileage if it's impossible to *start* the car without knowing that algorithm? Then, I think it's obvious the answer is, of course, no. If you buy the car, they have to tell you the algorithm. If knowledge of the algorithm is required to use the car in a reasonable way, even if it's not the normal expected way, then they can't keep it secret. They can't sell something while keeping secret how to *use* it. And that doesn't just mean the normal expected use. Buying something free and clear allows you to use it even in unusual ways. Perhaps that wasn't the best example. Let's try another one. You buy a car, and then discover that the car computer has a lockout and a code needs to be entered on the alarm panel to start the car between 4 AM and 4:15 AM on Tuesdays. You ask the manufacturer for that code, since you would like to start your car between 4 AM and 4:15 AM on Tuesdays even though many people don't. How many of the following answers would you consider fair: 1) We never wrote the code down. We knew it, but we didn't put it in a form in which we can give it to you. Most people don't need it anyway. Sorry. 2) We're sorry. We know the code, but our contract with another company prohibits us from disclosing it. And so on. Buying the car includes the right to start it between 4 AM and 4:15 AM on Tuesdays if that's what you want to do. If the manufacturer couldn't sell you the right or ability to do that, it couldn't sell you the car. Owning a video card includes the right to make it work with Linux if that's what you want to do. If the manufacturer couldn't sell you the right or ability to do that, it couldn't sell you the video card. Here's my personal favourite example: You walk into a car dealership to buy a new car, because your old car is too slow to drive on the freeway; you need something faster. The salesman shows you a great vehicle. He tells you all about how this car is the pinnacle of automotive technology. It's got muscle. It's got finesse. It's got tons of state of the art bells and whistles. Your friends will be s jealous. Chicks will dig you. You have to have it. You pay the man and have it delivered to you house. When it arrives, you can't figure out how to open the door. The front windows are opaque, so you can't see inside. You: Hey, delivery guy. How do I open the door on this thing?. Guy: I'm not the delivery guy. I'm your driver. You: Huh? Look, I don't need a driver, OK? I'll drive it myself. So how do I open the door? Driver: I'm sorry sir, but I can't tell you that. It's secret car company stuff. If I told you, then our competition might find out how we do it, and we would lose our competitive advantage. You: Whatever. I need to get to work. Let's go. You get in the back seat, but there is an opaque barrier between you and the front of the car. Driver: Just talk into the speaker on your left, sir, and I'll go where you tell me to. You get out on the freeway, but you're only going 30 kph. You: What the hell is wrong with this thing? I thought this car was the fastest thing on the road. Pick it up, why don't you? Driver: I'm sorry sir. I don't really know how to make the car go faster than 30 kph. This is a new model, and the company hasn't yet taught us how to drive it fast. Check in with them next month. They're always training new drivers, and they might have a replacement for you by then. You: Well that's just great. Let's get off the freeway. Take a left on Broadway, at the bottom of the off-ramp. You exit the freeway, but as you are turning left onto Broadway, your car stalls in the intersection. You: Hey driver, WTF? Driver: Sorry Sir, I seem t0 baeo ++_?+CFY^K$# ekbae. The driver stumbles out of the car and starts spazzing out on the ground. After a couple of minutes he's OK and you get back on the road. There's an uncomfortable silence in the car. You don't tell him to turn left any more. Six months later, the company sends you a replacement driver. Driver2: Sorry it took so long sir. You see, there's not much call for drivers who know the streets in this neighbourhood, or that speak your language. Most of our clients speak Esperanto, and are
Re: Freeing a dynamic struct cdev
Ok, I really blew it with that last post: > > cdev_add() calls: > kobj_map() > kobject_get() [indirectly] > This is wrong. When I first looked at it, I saw: cdev_add() -> kobj_map() -> exact_lock() -> cdev_get() -> kobject_get() but exact_lock() isn't called here; it is only passed as a function pointer to kobj_map(), and so calling cdev_add() does /not/ increment the reference count of the struct cdev. I guess what threw me for a loop here was that I was expecting separate functions: one to undo cdev_add() and one to undo cdev_alloc(), but cdev_del() accomplishes both tasks in one function, with the kobj_unmap() part having no effect, if the cdev is not mapped at the time of the call. -- James C. Georgas <[EMAIL PROTECTED]> - 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: Freeing a dynamic struct cdev
On Sat, 2005-08-06 at 12:21 -0700, Randy.Dunlap wrote: > On Sat, 06 Aug 2005 09:26:15 -0400 James C. Georgas wrote: > > > If I allocate a struct cdev using cdev_alloc(), what function do I call > > to free it when I'm done with it? > > Should be cdev_put(), which calls kobject_put(), which implements > ref counting (using krefs), so that when the last reference is > going away, the object will be removed. > > --- > ~Randy cdev_put() is not an exported symbol in the fs/char_dev.c file. Should it be? -- James C. Georgas <[EMAIL PROTECTED]> - 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: Freeing a dynamic struct cdev
On Sat, 2005-08-06 at 12:21 -0700, Randy.Dunlap wrote: On Sat, 06 Aug 2005 09:26:15 -0400 James C. Georgas wrote: If I allocate a struct cdev using cdev_alloc(), what function do I call to free it when I'm done with it? Should be cdev_put(), which calls kobject_put(), which implements ref counting (using krefs), so that when the last reference is going away, the object will be removed. --- ~Randy cdev_put() is not an exported symbol in the fs/char_dev.c file. Should it be? -- James C. Georgas [EMAIL PROTECTED] - 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: Freeing a dynamic struct cdev
Ok, I really blew it with that last post: cdev_add() calls: kobj_map() kobject_get() [indirectly] This is wrong. When I first looked at it, I saw: cdev_add() - kobj_map() - exact_lock() - cdev_get() - kobject_get() but exact_lock() isn't called here; it is only passed as a function pointer to kobj_map(), and so calling cdev_add() does /not/ increment the reference count of the struct cdev. I guess what threw me for a loop here was that I was expecting separate functions: one to undo cdev_add() and one to undo cdev_alloc(), but cdev_del() accomplishes both tasks in one function, with the kobj_unmap() part having no effect, if the cdev is not mapped at the time of the call. -- James C. Georgas [EMAIL PROTECTED] - 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/
Inclusion order patch
Excuse me for reposting this. I forgot the subject line. hehe.
This patch lets this header stand alone, since I can never remember
which other headers to include, or in which order.
The three #include lines define the types: kobject, list_head and dev_t,
which are used in the cdev structure.
The forward declaration of struct inode is to quiet the following
compiler warning when including only cdev.h in my file:
include/linux/cdev.h:30: warning: `struct inode' declared inside parameter list
include/linux/cdev.h:30: warning: its scope is only this definition or
declaration, which is probably not what you want
I'm not sure, but I think it's saying that I'm declaring a new struct,
which will not be the same as the real struct inode if it is #included
later, because of the scope rules.
(oh yeah, this is my first patch to the list; did I get the format
right?)
BEGIN PATCH:
diff -Nru linux-2.6.12.4/include/linux/cdev.h linux/include/linux/cdev.h
--- linux-2.6.12.4/include/linux/cdev.h 2005-08-05 03:04:37.0
-0400
+++ linux/include/linux/cdev.h 2005-08-05 21:41:39.0 -0400
@@ -2,6 +2,12 @@
#define _LINUX_CDEV_H
#ifdef __KERNEL__
+#include
+#include
+#include
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas <[EMAIL PROTECTED]>
-
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/
[no subject]
This patch lets this header stand alone, since I can never remember
which other headers to include, or in which order.
The three #include lines define the types: kobject, list_head and dev_t,
which are used in the cdev structure.
The forward declaration of struct inode is to quiet the following
compiler warning when including only cdev.h in my file:
include/linux/cdev.h:30: warning: its scope is only this definition or
declaration, which is probably not what you want
I'm not sure, but I think it's saying that I'm declaring a new struct,
which will not be the same as the real struct inode if it is #included
later, because of the scope rules.
(oh yeah, this is my first patch to the list; did I get the format
right?)
BEGIN PATCH:
diff -Nru linux-2.6.12.4/include/linux/cdev.h linux/include/linux/cdev.h
--- linux-2.6.12.4/include/linux/cdev.h 2005-08-05 03:04:37.0
-0400
+++ linux/include/linux/cdev.h 2005-08-05 21:41:39.0 -0400
@@ -2,6 +2,12 @@
#define _LINUX_CDEV_H
#ifdef __KERNEL__
+#include
+#include
+#include
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas <[EMAIL PROTECTED]>
-
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/
[no subject]
This patch lets this header stand alone, since I can never remember
which other headers to include, or in which order.
The three #include lines define the types: kobject, list_head and dev_t,
which are used in the cdev structure.
The forward declaration of struct inode is to quiet the following
compiler warning when including only cdev.h in my file:
include/linux/cdev.h:30: warning: its scope is only this definition or
declaration, which is probably not what you want
I'm not sure, but I think it's saying that I'm declaring a new struct,
which will not be the same as the real struct inode if it is #included
later, because of the scope rules.
(oh yeah, this is my first patch to the list; did I get the format
right?)
BEGIN PATCH:
diff -Nru linux-2.6.12.4/include/linux/cdev.h linux/include/linux/cdev.h
--- linux-2.6.12.4/include/linux/cdev.h 2005-08-05 03:04:37.0
-0400
+++ linux/include/linux/cdev.h 2005-08-05 21:41:39.0 -0400
@@ -2,6 +2,12 @@
#define _LINUX_CDEV_H
#ifdef __KERNEL__
+#include linux/kobject.h
+#include linux/list.h
+#include linux/types.h
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas [EMAIL PROTECTED]
-
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/
Inclusion order patch
Excuse me for reposting this. I forgot the subject line. hehe.
This patch lets this header stand alone, since I can never remember
which other headers to include, or in which order.
The three #include lines define the types: kobject, list_head and dev_t,
which are used in the cdev structure.
The forward declaration of struct inode is to quiet the following
compiler warning when including only cdev.h in my file:
include/linux/cdev.h:30: warning: `struct inode' declared inside parameter list
include/linux/cdev.h:30: warning: its scope is only this definition or
declaration, which is probably not what you want
I'm not sure, but I think it's saying that I'm declaring a new struct,
which will not be the same as the real struct inode if it is #included
later, because of the scope rules.
(oh yeah, this is my first patch to the list; did I get the format
right?)
BEGIN PATCH:
diff -Nru linux-2.6.12.4/include/linux/cdev.h linux/include/linux/cdev.h
--- linux-2.6.12.4/include/linux/cdev.h 2005-08-05 03:04:37.0
-0400
+++ linux/include/linux/cdev.h 2005-08-05 21:41:39.0 -0400
@@ -2,6 +2,12 @@
#define _LINUX_CDEV_H
#ifdef __KERNEL__
+#include linux/kobject.h
+#include linux/list.h
+#include linux/types.h
+
+struct inode;
+
struct cdev {
struct kobject kobj;
struct module *owner;
--
James C. Georgas [EMAIL PROTECTED]
-
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/
