Re: [patch 07/21] Xen-paravirt: remove ctor for pgd cache
Pekka Enberg wrote: On 2/16/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: Remove the ctor for the pgd cache. There's no point in having the cache machinery do this via an indirect call when all pgd are freed in the one place anyway. The reason we have slab constructors and destructors is to _avoid_ reinitializing every time we allocate an object. AFAICT your changing the code now to do _more_ work than before, so is there some other reason why you want to do this than avoiding an indirect call? Sometimes it is better for the caches to initialise an object immediately, but in this case I think it is better to use the slab ctor because it is very unlikely to use many cachelines immediately anyway. It would be nice to put the "why" in the changelogs, rather than "what". Not everyone wants to go through the whole patchset to decipher why Xen possibly needs something. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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 12/21] Xen-paravirt: Allocate and free vmalloc areas
> It's for populating the pagetable in a vmalloc area. There's magic in If the lazy setup doesn't work for you you can always call vmalloc_sync() early. -Andi - 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: GPL vs non-GPL device drivers
> I'll say that again, for everyone else who is reading this: the GPL > makes it really clear that extensions to a GPL work are required to be > distributed under the terms of the GPL. All this junk about > "derivative works" is just the legal jargon used to implement the > intent of the GPL. You can argue that a particular extension isn't a > derivative work if you want, but you can't argue with the intent.. > cause it is written in plain english. I don't think it was the intent of the GPL that if you want to make drivers for a GPL'd operating system, you must make the drivers GPL'd. That seems like precisely the sort of software-patent oligopoly (owning every way to do a particular thing) that the GPL was intended to combat. I quote from Stallman: "Nobody is trying to patent specific programs; that isn't allowed, but nobody would bother even if it was allowed. A patent covering one specific program would not really matter to anyone. The reason why these patents create an issue is that they're not about specific programs, they're much more general. Each of these patents covers an idea that you might use in implementing various different programs, that lots of different programmers might use, might put into the programs that they are writing. And that's what makes them obstacles and dangers to software development activity." This is precisely what "every Linux driver is a derivative work of my work" is saying. It is totally counter to the spirit and intent of the GPL. Every time you say, "that's a derivative work and you need to follow the rules", that's one less situation where you can say, "this is fair use" in an analogous case with a commercial work. If closed source drivers are against the spirit of the GPL, then it's not fair use to tinker with a commercial work to get it to work with your hardware. Most certainly the spirit of the GPL is that it's fair use to tinker with a work to get it to work on your hardware. Is it not fair use to share that with other licensees of the original work? Should Microsoft be able to prevent me from distributing patches to Windows that fix bugs or add features? It is so funny that the GPL community is succumbing to the same desire to expand intellectual property rights to get more control over their work that they condemn in the closed source world. The open source community should be trying to expand fair use, not expand derivative works. In addition, it is quite clear legally that if you take only what every attempt to perform the same function must take, you are not a derivative work. That is, if you are writing a Linux driver for an X1950 graphics card, you can take what any Linux driver for an X1950 graphics could would reasonably need to take. (See, among other cases, Lexmark. v. Static Controls.) A copyright is not a patent, you can only own something if there are multiple equally good ways to do it and you claim *one* of them. DS - 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: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 21:48 -0800, v j wrote: > We only get crap because no one here yet knows how to interpret > proprietary modules loaded into the kernel. The proprietary modules where only a tiny wrapper is linux-specific and the rest is cross-platform are in a grey area, yes. But your modules, written specifically for linux but distributed as binary-only, are specifically what the people choosing the GPL want to avoid. They are a derivative work, and are, as such, illegal under the GPL. As stated by multiple other people, please consult a lawyer if you want to be nasty. Or just play by the rules. Xav - 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 04/21] Xen-paravirt: ===================================================================
Subject? description? On Thu, Feb 15, 2007 at 06:24:53PM -0800, Jeremy Fitzhardinge wrote: > -static void vmi_set_pte_present(struct mm_struct *mm, unsigned long addr, > pte_t *ptep, pte_t pte) > +static void vmi_set_pte_present(struct mm_struct *mm, u32 addr, pte_t *ptep, > pte_t pte) And what good is that change anyways? unsigned long is the usual style for addresses. -Andi - 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: FW: [PATCH] i386: irq: Kill IRQ compression
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 12:44 AM To: Len Brown Cc: Andi Kleen; Protasevich, Natalie; lkml - Kernel Mailing List; linux-acpi@vger.kernel.org Subject: Re: [PATCH] i386: irq: Kill IRQ compression Len Brown <[EMAIL PROTECTED]> writes: > This code makes simple systems complex: > > ACPI: PCI Interrupt :03:04.0[A] -> GSI 18 (level, low) -> IRQ 16 > ACPI: PCI Interrupt :00:1d.0[A] -> GSI 16 (level, low) -> IRQ 17 > ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 18 > ACPI: PCI Interrupt :00:1d.7[D] -> GSI 23 (level, low) -> IRQ 19 > > The same code was already removed from x86_64 By itself I don't think we are going to observe any real problems with this patch. However if we are going to be serious about this we need to do a few more things. - kill iopaic_renumber_irq. This routine actually renumbers gsi's. I don't think you can kill ioapic_renumber_irq without bringing down ES7000 that have swapped legacy/PCI ranges and are still out there. Moreover, mach-es7000 purpose is to define and use the range swapper on the first ioapic. Kernel still assumes legacy mapping having no overrides of that extent. Perhaps the real fix is to have ACPI/MPS parsers to read the actual pin/gsi information from the tables, which turned out pretty difficult last time we tried. --Natalie - Increase NR_IRQS. We will still be limited to about 208 interrupts in use at one time, but we can allow more irq sources to be described. This reminds me. I really need to dig up my patch that doesn't allocate a vector for an irq until request irq time. Eric - 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] i386: adjustments to page table dump during oops (v4)
- make the page table contents printing PAE capable
- make sure the address stored in current->thread.cr2 is unmodified
from what was read from CR2
- don't call oops_may_print() multiple times, when one time suffices
- print pte even in highpte case, as long as the pte page isn't in
actually in high memory (which is specifically the case for all page
tables covering kernel space)
(Changes to v3: Use sizeof()*2 rather than the suggested sizeof()*4 for
printing width, use fixed 16-nibble width for PAE, and also apply the
max_low_pfn range check to the middle level lookup on PAE.)
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- linux-2.6.20/arch/i386/mm/fault.c 2007-02-04 19:44:54.0 +0100
+++ 2.6.20-i386-page-fault-dump/arch/i386/mm/fault.c2007-02-14
08:31:38.0 +0100
@@ -20,6 +20,7 @@
#include
#include /* For unblank_screen() */
#include
+#include /* for max_low_pfn */
#include
#include
#include
@@ -327,7 +328,6 @@ fastcall void __kprobes do_page_fault(st
struct mm_struct *mm;
struct vm_area_struct * vma;
unsigned long address;
- unsigned long page;
int write, si_code;
/* get the address */
@@ -538,7 +538,9 @@ no_context:
bust_spinlocks(1);
if (oops_may_print()) {
- #ifdef CONFIG_X86_PAE
+ __typeof__(pte_val(__pte(0))) page;
+
+#ifdef CONFIG_X86_PAE
if (error_code & 16) {
pte_t *pte = lookup_address(address);
@@ -547,7 +549,7 @@ no_context:
"NX-protected page - exploit attempt? "
"(uid: %d)\n", current->uid);
}
- #endif
+#endif
if (address < PAGE_SIZE)
printk(KERN_ALERT "BUG: unable to handle kernel NULL "
"pointer dereference");
@@ -557,25 +559,38 @@ no_context:
printk(" at virtual address %08lx\n",address);
printk(KERN_ALERT " printing eip:\n");
printk("%08lx\n", regs->eip);
- }
- page = read_cr3();
- page = ((unsigned long *) __va(page))[address >> 22];
- if (oops_may_print())
+
+ page = read_cr3();
+ page = ((__typeof__(page) *) __va(page))[address >>
PGDIR_SHIFT];
+#ifdef CONFIG_X86_PAE
+ printk(KERN_ALERT "*pdpt = %016Lx\n", page);
+ if ((page >> PAGE_SHIFT) < max_low_pfn
+ && page & _PAGE_PRESENT) {
+ page &= PAGE_MASK;
+ page = ((__typeof__(page) *) __va(page))[(address >>
PMD_SHIFT)
+&
(PTRS_PER_PMD - 1)];
+ printk(KERN_ALERT "*pde = %016Lx\n", page);
+ page &= ~_PAGE_NX;
+ }
+#else
printk(KERN_ALERT "*pde = %08lx\n", page);
- /*
-* We must not directly access the pte in the highpte
-* case, the page table might be allocated in highmem.
-* And lets rather not kmap-atomic the pte, just in case
-* it's allocated already.
-*/
-#ifndef CONFIG_HIGHPTE
- if ((page & 1) && oops_may_print()) {
- page &= PAGE_MASK;
- address &= 0x003ff000;
- page = ((unsigned long *) __va(page))[address >> PAGE_SHIFT];
- printk(KERN_ALERT "*pte = %08lx\n", page);
- }
#endif
+
+ /*
+* We must not directly access the pte in the highpte
+* case if the page table is located in highmem.
+* And let's rather not kmap-atomic the pte, just in case
+* it's allocated already.
+*/
+ if ((page >> PAGE_SHIFT) < max_low_pfn
+ && (page & _PAGE_PRESENT)) {
+ page &= PAGE_MASK;
+ page = ((__typeof__(page) *) __va(page))[(address >>
PAGE_SHIFT)
+&
(PTRS_PER_PTE - 1)];
+ printk(KERN_ALERT "*pte = %0*Lx\n", sizeof(page)*2,
(u64)page);
+ }
+ }
+
tsk->thread.cr2 = address;
tsk->thread.trap_no = 14;
tsk->thread.error_code = error_code;
-
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 05/11] syslets: core code
On Thu, Feb 15, 2007 at 11:28:57AM -0800, Linus Torvalds ([EMAIL PROTECTED]) wrote: > THAT was the point. Interfaces are really really subtle and important. > It's absolutely not a case of "we can just write wrappers to fix up any > library issues". Interfaces can be created and destroyed - they do not affect overall system design in anyway (well, if they do, something is broken). So let's solve problems in order of their appearence - if interfaces are more important for you than overall design - that is a problem I think. > > So instead there will be > > s = atom_create_and_add(__NR_stat, path, stat, NULL, NULL, NULL, NULL); > > atom then can be freed in the glibc_async_wait() wrapper just before > > returning data to userspace. > > So now you add some kind of allocation/dealloction thing. In user space or > in the kernel? In userspace. It was not added by me - it is just a wrapper. > > There are millions of possible ways to do that, but what exactly one > > should be used from your point of view? Describe _your_ vision of that path. > > My vision is that we should be able to do the simple things *easily* and > without any extra overhead. > > And doing wrappers in user space is almost entirely unacceptable, becasue > a lot of the wrapping needs to be done at release time (for example: > de-allocating memory), and that means that you no longer can do simple > system calls that don't even need release notification AT ALL. syslets do work that way - they require some user memory - likely long-standing (100% sure for multi atom setup, maybe it can be optimized though) - if you do not want to allocate it explicitly - it is possible to have a wrapper. > > Currently generic example is following: > > allocate mem > > setup complex structure > > submit syscall > > wait syscall > > free mem > > And that "allocate mem" and "free mem" is a problem. It's not just a > performance problem, it is a _complexity_ problem. It means that people > have to track things that they are NOT AT ALL INTERESTED IN! I proposed a way to hide allocation - it is simple, but you've cut it. I can create another one without special per-thread thing - handle = async_init(); async_stat(handle, path, stat); async_cleanup(); // not needed, since will be freed on exit automatically Another one is to preallocate set of atoms in __attribute((contructor)) function. There are really a lot of possible ways - _I_ can use the first one with explicit operations, others likely can not - so I _ask_ about how should it look like. > > So, describe how exactly _you_ think it should be implemented with its > > pros and cons, so that systemn could be adopted without trying to > > mind-read of what is simple and good or complex and really bad. > > So I think that a good implementation just does everything up-front, and > doesn't _need_ a user buffer that is live over longer periods, except for > the actual results. Exactly because the whole alloc/teardown is nasty. > > And I think a good implementation doesn't need wrapping in user space to > be useful - at *least* not wrapping at completion time, which is the > really difficult one (since, by definition, in an async world completion > is separated from the initial submit() event, and with kernel-only threads > you actually want to *avoid* having to do user code after the operation > completed). So where is a problem? I proposed already three ways to do the thing - user will not even know about something happend. You did not comment on anyone, instead you handwaving with talks about how in theory something should be similar to. What exactly do _you_ expect from interface? > I suspect Ingo's thing can do that. But I also suspect (nay, _know_, from > this discussion), that you didn't even think of the problems. That is another problem - you think you know something, but you fail to prove that. I can work with explicit structure allocation/deallocation/setup - you do not want that - so I ask you about your opinion, and instead of getting an answer I receive theoretical word-fall about how perfect interface should look like. You only need to have one function call without ever thinking bout freeing? I proposed _two_ ways to that. You can live with explicit init/cleanup (opt) code? There is another one. So please decribe your vision of interface with details, so that it could be think about or/and implemented. > Linus -- Evgeniy Polyakov - 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: kbuild question
> > Now is there some way to not have to duplicate the 'config choices > between if ONLY_HAVE_ONE and if !ONLY_HAVE_ONE > > To use your example I want to do: > > config ONLY_HAVE_ONE > prompt "only have one?" > boolean > > if ONLY_HAVE_ONE > config VAL_FIRST > bool "First value" > > config VAL_SECOND > bool "Second value" > endif > > if !ONLY_HAVE_ONE > choice > prompt "multiple values" > default VAL_FIRST > > config VAL_FIRST > bool "First value" > > config VAL_SECOND > bool "Second value" > endchoice > > endif > > I'd like not to have to repeat/duplicate VAL_FIRST, VAL_SECOND, etc.. A choice allow you to select multiple values if the type of all choice entries are of type 'tristate' but this gets enabled only when CONFIG_MODULES equal to 'y'. So except if you really need the 'select multiple' when MODULES are selected I see no easy way to achive what you want. I did not try but carefull usage of 'depends on' could also help you but it will get messy quite fast. Maybe Roman can se a better way? Sam - 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 07/21] Xen-paravirt: remove ctor for pgd cache
On 2/16/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: Remove the ctor for the pgd cache. There's no point in having the cache machinery do this via an indirect call when all pgd are freed in the one place anyway. The reason we have slab constructors and destructors is to _avoid_ reinitializing every time we allocate an object. AFAICT your changing the code now to do _more_ work than before, so is there some other reason why you want to do this than avoiding an indirect call? - 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: Problem with 2.6.20 and highmem64
I can confirm that it works fine with 2.6.20-rc2. Do you need me to try any other ? do you need any more info ? 2007/2/14, Nilshar <[EMAIL PROTECTED]>: Hello, I have an issue with latest 2.6.20 kernel.. my last kernel was a 2.6.18 and I wanted to upgrade to a 2.6.20, I copied .config and did a make menuconfig, then save/quit. I compiled new kernel, all went fine. I installed it and at boot time, I had a hang just after "Freeing unused kernel memory" where INIT is supposed to start. After searching the web, I found that it is usually the case when wrong process type is configured.. I verified that, but all was fine there. After 10ish compiled kernel, I found that it is when I select highmem64. Diff between working and non working kernel : 181,182c181,182 < # CONFIG_HIGHMEM4G is not set < CONFIG_HIGHMEM64G=y --- > CONFIG_HIGHMEM4G=y > # CONFIG_HIGHMEM64G is not set 185d184 < CONFIG_X86_PAE=y 191c190 < CONFIG_RESOURCES_64BIT=y --- > # CONFIG_RESOURCES_64BIT is not set (I just witching highmem 4G and highmem64g). I'll attach the full .config. it used to work fine with highmem64g with a kernel 2.6.18 and 2.6.19 (I'm sure it was ok with .20-rc2 but I'll double check that). Is this a bug ? or something I did wrong ? Oh, I probably should add that this hang doesn't occur on all hardware, but it happen on Dell PE 850 at least. If you need additional informations, just ask :) - 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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
On 02/16/2007 12:05 AM, Jeremy Fitzhardinge wrote: Dan Hecht wrote: On 02/15/2007 11:04 PM, Jeremy Fitzhardinge wrote: HZ - I'm assuming dynticks will appear in the short term, and this will become moot Doesn't Xen send any non-blocked domain a 100hz alarm implicitly, without anyway for the guest to disable it? I guess you'll have to break kernel/hypervisor compatibility if you want dynticks? The timer VIRQ will generate events at a fixed 100Hz (which can be masked, like any other event), but you can also ask for a timer event at a particular time. We do this already for tickless idle. J Hmm? I thought the periodic timer and one-shot timer both generate the same VIRQ. So, how can you mask one without masking the other? The tickless idle works since the block hypercall disables the periodic timer. But for dynticks (aka NO_HZ), you'll need to mask the periodic timer (even for a running vcpu), while keeping the one-shot timer unmasked. I don't think Xen provides an interface to do that. Dan - 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: GPL vs non-GPL device drivers
Hello! > Assuming these need not be GPL, I have a problem with > EXPORT_SYMBOL_GPL and the general trend in the direction of making > proprietary drivers harder on companies. Most kernel developers did always say they don't agree with proprietary drivers, don't want to support them and that they are convinced such drivers are illegal. And according to the language of the GPL and the copyright law, it's quite possible they really are illegal (although a court _might_ rule that the modules are not a derived work of the kernel). Even with all that, you still decided to distribute such modules. What you are complaining about? > So why beat about the bush? Just make it illegal to load proprietary > drivers, or remove EXPORT_SYMBOL_GPL. The point is that it's impossible to make it illegal (although many of the authors of the kernel would like to) -- the point is that if kernel modules aren't derivative works of the kernel, the kernel license cannot control them. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth This mail doesn't contain viruses, because it wasn't sent from MS Windows. Checked by eyes. - 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: [2.6 patch] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module
On Fri, Feb 16, 2007 at 01:17:19AM +0100, Tilman Schmidt wrote: > Am 15.02.2007 22:56 schrieb Adrian Bunk: > > This patch fixes the following compile error: > > > > <-- snip --> > > > > ... > > LD drivers/isdn/gigaset/built-in.o > > drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb': > > (.text+0xe50): multiple definition of `gigaset_m10x_send_skb' > > drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here > > drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_input': > > (.text+0x1121): multiple definition of `gigaset_m10x_input' > > drivers/isdn/gigaset/usb_gigaset.o:(.text+0x2d1): first defined here > > make[4]: *** [drivers/isdn/gigaset/built-in.o] Error 1 > > How did you manage to produce that error? I have never encountered it. CONFIG_ISDN_DRV_GIGASET=y CONFIG_GIGASET_BASE=y CONFIG_GIGASET_M105=y CONFIG_GIGASET_M101=y CONFIG_GIGASET_DEBUG=y CONFIG_GIGASET_UNDOCREQ=y It might depend on the binutils version. > Thanks, > Tilman cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Eric W. Biederman wrote: Ian Campbell <[EMAIL PROTECTED]> writes: On Fri, 2007-02-16 at 00:33 -0700, Eric W. Biederman wrote: I know there actually has been some work to get kexec actually working under Xen but I don't know where that has gone. kexec/kdump works with Xen 3.0.4 but it's a dom0 only thing so it doesn't appear in this patchset. Ok but we still need to get the failure to user space for domU instead of trying what works on real hardware and failing. Eric Acked-by: Zachary Amsden <[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: 2.6.20-rt5 Oops on boot [-rt8 OK]
* Rui Nuno Capela <[EMAIL PROTECTED]> wrote: > Rui Nuno Capela (me) wrote: > > > > I have terrible news: 2.6.20-rt5 does not boot at all on a couple > > machines I was brave enough to try -- a [EMAIL PROTECTED] SMP/HT desktop, > > and a > > Core2 Duo [EMAIL PROTECTED] laptop. For the first case I could capture the > > following dump via serial console: > > ... > > News are that 2.6.20-rt8 got it all back to business :) great! The fix is from Michal/Clark/Steve. Ingo - 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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
On Fri, 2007-02-16 at 00:33 -0700, Eric W. Biederman wrote: > I know there actually has been some work to get kexec actually working under > Xen but I don't know where that has gone. kexec/kdump works with Xen 3.0.4 but it's a dom0 only thing so it doesn't appear in this patchset. Ian. - 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 2.6.20-git] remove modpost false warnings on ARM
On Thu, Feb 15, 2007 at 07:10:45PM -0800, David Brownell wrote: > This patch stops "modpost" from issuing erroneous modpost warnings on ARM > builds, which it's been doing since since maybe last summer. A canonical > example would be driver method table entries: > > WARNING: - Section mismatch: reference to .exit.text:_remove > from .data after '$d' (at offset 0x4) > > That "$d" symbol is generated by tools conformant with ARM ABI specs; in > this case it's a symbol **in the middle of** a "_driver" struct. > > The erroneous warnings appear to be issued because "modpost" whitelists > references from "_driver" data into init and exit sections ... but > doesn't know should also include those "$d" mapping symbols, which are > not otherwise associated with "_driver" symbols. > > This patch prevents the modpost symbol lookup code from ever returning > those mapping symbols, so it will return a whitelisted symbol instead. > Then things work as expected. > > Now to revert various code-bloating "fixes" that got merged because of > this modpost bug > > Signed-off-by: David Brownell <[EMAIL PROTECTED]> Acked-by: Sam Ravnborg <[EMAIL PROTECTED]> And if I get my dev machine operational before akpm merges this I will take care of having it merged. - 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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Ian Campbell <[EMAIL PROTECTED]> writes: > On Fri, 2007-02-16 at 00:33 -0700, Eric W. Biederman wrote: >> I know there actually has been some work to get kexec actually working under >> Xen but I don't know where that has gone. > > kexec/kdump works with Xen 3.0.4 but it's a dom0 only thing so it > doesn't appear in this patchset. Ok but we still need to get the failure to user space for domU instead of trying what works on real hardware and failing. Eric - 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: GPL vs non-GPL device drivers
On Thu, 15 Feb 2007 09:32:30 EST, "linux-os (Dick Johnson)" said: > There are a lot of device drivers that will never make it into the > mainline kernel because they are for one-of-a-kind devices or boards > that companies embed into their products. Nobody would even want a > copy of the software to interface with something that they would > never even have. When Version 2.6 started, it became necessary to > use special tools and procedures to compile a module that was not > inside the mainline kernel. However, it was still quite easy. Recently, > somebody, apparently with an advanced degree in obfuscation, has made > that more difficult. This is abuse, pure and simple. That, in my > opinion, is one of the major reasons why people who use Linux in > embedded systems end up using very old versions. Actually, the *real* reason embedded systems end up using old versions is much simpler. They start developing their code on release 2.X.Y, and they keep their code out-of-tree. Then, when they come up for air, and it's at 2.X.(Y+15), they discover that we weren't kidding when we shipped stable_api_nonsense.txt, and since their code isn't in the tree, they have to do all the API cleanup themselves, because no flock of nit-picking kernel janitor monkeys swarmed over their code and magically fixed it up for them. And unless Y+15 has some *very* compelling reasons to move forward, just sticking at Y suddenly starts looking very good, because watching somebody else's kernel janitor monkeys fix your code is fairly cheap, but paying your own kernel janitor monkeys gets expensive really fast pgpsQudmMGmoh.pgp Description: PGP signature
Re: [PATCH] Add Cobalt button interface driver support
Hi,
Thank you for your comments.
On Thu, 15 Feb 2007 23:09:43 -0500
Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> On Thursday 15 February 2007 22:36, Yoichi Yuasa wrote:
> > Hi,
> >
> > This patch adds support for the back panel buttons on Cobalt server.
> > It's tested on the Cobalt Qube2.
> >
>
> Hi,
>
> Thank you for your patch. Couple of comments:
>
> > +
> > + button++;
> > + }
> > +
> > + mod_timer(_timer, jiffies + HZ / BUTTONS_POLL_FREQUENCY);
>
> May I suggest using msecs_to_jiffies() to avoid direct computations on HZ?
OK, I updated it.
> > +
> > + bdev->input = input;
> > + bdev->reg = ioremap(res->start, res->end - res->start + 1);
> > + dev_set_drvdata(>dev, bdev);
> > +
> > + setup_timer(_timer, handle_buttons, (unsigned long)bdev);
> > + mod_timer(_timer, jiffies + HZ / BUTTONS_POLL_FREQUENCY);
>
> Please implement cobalt_buttons_open() and cobalt_buttons_close() methods
> and start/stop timer from there - there is no point in polling hardware
> if noone is listening to the events.
I updated it too.
> > +static int __devexit cobalt_buttons_remove(struct platform_device *pdev)
> > +{
> > + struct device *dev = >dev;
> > + struct buttons_dev *bdev = dev_get_drvdata(dev);
> > +
> > + del_timer(_timer);
>
> del_timer_sync? Is there any possibility it may run SMP?
Cobalt server doesn't support SMP. but there is no problem.
I updated it.
> > +static void __exit cobalt_buttons_exit(void)
> > +{
> > + platform_driver_unregister(_buttons_driver);
>
> You are not allowed to unregister statically allocated devices -
> if there are references left and your module goes away then
> these references become invalid and kernel goes boom.
>
> Please convert to platform_device_alloc/platform_device_add.
I updated it.
> Is there a point of moving platform device creation code into
> platform-specific code? Is there a possibility of this driver
> being used elsewhere?
No it isn't.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -pruN -X mips/Documentation/dontdiff mips-orig/drivers/input/misc/Kconfig
mips/drivers/input/misc/Kconfig
--- mips-orig/drivers/input/misc/Kconfig2007-02-14 15:35:30.566862000
+0900
+++ mips/drivers/input/misc/Kconfig 2007-02-15 17:20:28.721985250 +0900
@@ -89,4 +89,10 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config INPUT_COBALT_BTNS
+ tristate "Cobalt button interface"
+ depends on MIPS_COBALT
+ help
+ Say Y here if you want to support MIPS Cobalt button interface.
+
endif
diff -pruN -X mips/Documentation/dontdiff mips-orig/drivers/input/misc/Makefile
mips/drivers/input/misc/Makefile
--- mips-orig/drivers/input/misc/Makefile 2007-02-14 15:35:30.566862000
+0900
+++ mips/drivers/input/misc/Makefile2007-02-15 11:55:30.856042500 +0900
@@ -12,3 +12,4 @@ obj-$(CONFIG_INPUT_WISTRON_BTNS) += wist
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
diff -pruN -X mips/Documentation/dontdiff
mips-orig/drivers/input/misc/cobalt_btns.c mips/drivers/input/misc/cobalt_btns.c
--- mips-orig/drivers/input/misc/cobalt_btns.c 1970-01-01 09:00:00.0
+0900
+++ mips/drivers/input/misc/cobalt_btns.c 2007-02-16 16:09:48.857365000
+0900
@@ -0,0 +1,233 @@
+/*
+ * Cobalt button interface driver.
+ *
+ * Copyright (C) 2007 Yoichi Yuasa <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define BUTTONS_POLL_INTERVAL 30 /* msec */
+#define BUTTONS_COUNT_THRESHOLD3
+#define BUTTONS_STATUS_MASK0xfe00
+
+struct buttons_dev {
+ struct input_dev *input;
+ void __iomem *reg;
+};
+
+struct buttons_map {
+ uint32_tmask;
+ int keycode;
+ int count;
+};
+
+static struct buttons_map buttons_map[] = {
+ { 0x0200, KEY_RESTART, },
+ { 0x0400, KEY_LEFT, },
+ { 0x0800, KEY_UP, },
+ {
Re: [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core
On Fri, Feb 16, 2007 at 12:46:17PM +0530, Srivatsa Vaddagiri wrote:
> frozen. The only exception is cleaning up of per-cpu threads (which is
> not possible with processes frozen - if we can find a way to make that
> possible, then everything can be done in CPU_DEAD).
How abt a patch like below?
--- process.c.org 2007-02-16 13:38:39.0 +0530
+++ process.c 2007-02-16 13:38:59.0 +0530
@@ -47,7 +47,7 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(>sighand->siglock);
- while (frozen(current)) {
+ while (frozen(current) && !kthread_should_stop()) {
current->state = TASK_UNINTERRUPTIBLE;
schedule();
}
This should let us do kthread_stop() in CPU_DEAD itself (while processes
are frozen)? That would allow us to do everything from CPU_DEAD itself
(and not have CPU_DEAD_KILL_THREADS).
--
Regards,
vatsa
-
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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Dan Hecht wrote: > On 02/15/2007 11:04 PM, Jeremy Fitzhardinge wrote: >> HZ - I'm assuming dynticks will appear in the short term, and this will >> become moot > > Doesn't Xen send any non-blocked domain a 100hz alarm implicitly, > without anyway for the guest to disable it? I guess you'll have to > break kernel/hypervisor compatibility if you want dynticks? The timer VIRQ will generate events at a fixed 100Hz (which can be masked, like any other event), but you can also ask for a timer event at a particular time. We do this already for tickless idle. J - 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: [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core
On Fri, Feb 16, 2007 at 12:46:17PM +0530, Srivatsa Vaddagiri wrote:
frozen. The only exception is cleaning up of per-cpu threads (which is
not possible with processes frozen - if we can find a way to make that
possible, then everything can be done in CPU_DEAD).
How abt a patch like below?
--- process.c.org 2007-02-16 13:38:39.0 +0530
+++ process.c 2007-02-16 13:38:59.0 +0530
@@ -47,7 +47,7 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock);
- while (frozen(current)) {
+ while (frozen(current) !kthread_should_stop()) {
current-state = TASK_UNINTERRUPTIBLE;
schedule();
}
This should let us do kthread_stop() in CPU_DEAD itself (while processes
are frozen)? That would allow us to do everything from CPU_DEAD itself
(and not have CPU_DEAD_KILL_THREADS).
--
Regards,
vatsa
-
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: GPL vs non-GPL device drivers
On Thu, 15 Feb 2007 09:32:30 EST, linux-os (Dick Johnson) said: There are a lot of device drivers that will never make it into the mainline kernel because they are for one-of-a-kind devices or boards that companies embed into their products. Nobody would even want a copy of the software to interface with something that they would never even have. When Version 2.6 started, it became necessary to use special tools and procedures to compile a module that was not inside the mainline kernel. However, it was still quite easy. Recently, somebody, apparently with an advanced degree in obfuscation, has made that more difficult. This is abuse, pure and simple. That, in my opinion, is one of the major reasons why people who use Linux in embedded systems end up using very old versions. Actually, the *real* reason embedded systems end up using old versions is much simpler. They start developing their code on release 2.X.Y, and they keep their code out-of-tree. Then, when they come up for air, and it's at 2.X.(Y+15), they discover that we weren't kidding when we shipped stable_api_nonsense.txt, and since their code isn't in the tree, they have to do all the API cleanup themselves, because no flock of nit-picking kernel janitor monkeys swarmed over their code and magically fixed it up for them. And unless Y+15 has some *very* compelling reasons to move forward, just sticking at Y suddenly starts looking very good, because watching somebody else's kernel janitor monkeys fix your code is fairly cheap, but paying your own kernel janitor monkeys gets expensive really fast pgpsQudmMGmoh.pgp Description: PGP signature
Re: [patch 2.6.20-git] remove modpost false warnings on ARM
On Thu, Feb 15, 2007 at 07:10:45PM -0800, David Brownell wrote: This patch stops modpost from issuing erroneous modpost warnings on ARM builds, which it's been doing since since maybe last summer. A canonical example would be driver method table entries: WARNING: path - Section mismatch: reference to .exit.text:name_remove from .data after '$d' (at offset 0x4) That $d symbol is generated by tools conformant with ARM ABI specs; in this case it's a symbol **in the middle of** a name_driver struct. The erroneous warnings appear to be issued because modpost whitelists references from name_driver data into init and exit sections ... but doesn't know should also include those $d mapping symbols, which are not otherwise associated with name_driver symbols. This patch prevents the modpost symbol lookup code from ever returning those mapping symbols, so it will return a whitelisted symbol instead. Then things work as expected. Now to revert various code-bloating fixes that got merged because of this modpost bug Signed-off-by: David Brownell [EMAIL PROTECTED] Acked-by: Sam Ravnborg [EMAIL PROTECTED] And if I get my dev machine operational before akpm merges this I will take care of having it merged. - 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: [2.6 patch] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module
On Fri, Feb 16, 2007 at 01:17:19AM +0100, Tilman Schmidt wrote: Am 15.02.2007 22:56 schrieb Adrian Bunk: This patch fixes the following compile error: -- snip -- ... LD drivers/isdn/gigaset/built-in.o drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb': (.text+0xe50): multiple definition of `gigaset_m10x_send_skb' drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_input': (.text+0x1121): multiple definition of `gigaset_m10x_input' drivers/isdn/gigaset/usb_gigaset.o:(.text+0x2d1): first defined here make[4]: *** [drivers/isdn/gigaset/built-in.o] Error 1 How did you manage to produce that error? I have never encountered it. CONFIG_ISDN_DRV_GIGASET=y CONFIG_GIGASET_BASE=y CONFIG_GIGASET_M105=y CONFIG_GIGASET_M101=y CONFIG_GIGASET_DEBUG=y CONFIG_GIGASET_UNDOCREQ=y It might depend on the binutils version. Thanks, Tilman cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: GPL vs non-GPL device drivers
Hello! Assuming these need not be GPL, I have a problem with EXPORT_SYMBOL_GPL and the general trend in the direction of making proprietary drivers harder on companies. Most kernel developers did always say they don't agree with proprietary drivers, don't want to support them and that they are convinced such drivers are illegal. And according to the language of the GPL and the copyright law, it's quite possible they really are illegal (although a court _might_ rule that the modules are not a derived work of the kernel). Even with all that, you still decided to distribute such modules. What you are complaining about? So why beat about the bush? Just make it illegal to load proprietary drivers, or remove EXPORT_SYMBOL_GPL. The point is that it's impossible to make it illegal (although many of the authors of the kernel would like to) -- the point is that if kernel modules aren't derivative works of the kernel, the kernel license cannot control them. Have a nice fortnight -- Martin `MJ' Mares [EMAIL PROTECTED] http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth This mail doesn't contain viruses, because it wasn't sent from MS Windows. Checked by eyes. - 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: Problem with 2.6.20 and highmem64
I can confirm that it works fine with 2.6.20-rc2. Do you need me to try any other ? do you need any more info ? 2007/2/14, Nilshar [EMAIL PROTECTED]: Hello, I have an issue with latest 2.6.20 kernel.. my last kernel was a 2.6.18 and I wanted to upgrade to a 2.6.20, I copied .config and did a make menuconfig, then save/quit. I compiled new kernel, all went fine. I installed it and at boot time, I had a hang just after Freeing unused kernel memory where INIT is supposed to start. After searching the web, I found that it is usually the case when wrong process type is configured.. I verified that, but all was fine there. After 10ish compiled kernel, I found that it is when I select highmem64. Diff between working and non working kernel : 181,182c181,182 # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y --- CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set 185d184 CONFIG_X86_PAE=y 191c190 CONFIG_RESOURCES_64BIT=y --- # CONFIG_RESOURCES_64BIT is not set (I just witching highmem 4G and highmem64g). I'll attach the full .config. it used to work fine with highmem64g with a kernel 2.6.18 and 2.6.19 (I'm sure it was ok with .20-rc2 but I'll double check that). Is this a bug ? or something I did wrong ? Oh, I probably should add that this hang doesn't occur on all hardware, but it happen on Dell PE 850 at least. If you need additional informations, just ask :) - 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: kbuild question
Now is there some way to not have to duplicate the 'config choices between if ONLY_HAVE_ONE and if !ONLY_HAVE_ONE To use your example I want to do: config ONLY_HAVE_ONE prompt only have one? boolean if ONLY_HAVE_ONE config VAL_FIRST bool First value config VAL_SECOND bool Second value endif if !ONLY_HAVE_ONE choice prompt multiple values default VAL_FIRST config VAL_FIRST bool First value config VAL_SECOND bool Second value endchoice endif I'd like not to have to repeat/duplicate VAL_FIRST, VAL_SECOND, etc.. A choice allow you to select multiple values if the type of all choice entries are of type 'tristate' but this gets enabled only when CONFIG_MODULES equal to 'y'. So except if you really need the 'select multiple' when MODULES are selected I see no easy way to achive what you want. I did not try but carefull usage of 'depends on' could also help you but it will get messy quite fast. Maybe Roman can se a better way? Sam - 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 05/11] syslets: core code
On Thu, Feb 15, 2007 at 11:28:57AM -0800, Linus Torvalds ([EMAIL PROTECTED]) wrote: THAT was the point. Interfaces are really really subtle and important. It's absolutely not a case of we can just write wrappers to fix up any library issues. Interfaces can be created and destroyed - they do not affect overall system design in anyway (well, if they do, something is broken). So let's solve problems in order of their appearence - if interfaces are more important for you than overall design - that is a problem I think. So instead there will be s = atom_create_and_add(__NR_stat, path, stat, NULL, NULL, NULL, NULL); atom then can be freed in the glibc_async_wait() wrapper just before returning data to userspace. So now you add some kind of allocation/dealloction thing. In user space or in the kernel? In userspace. It was not added by me - it is just a wrapper. There are millions of possible ways to do that, but what exactly one should be used from your point of view? Describe _your_ vision of that path. My vision is that we should be able to do the simple things *easily* and without any extra overhead. And doing wrappers in user space is almost entirely unacceptable, becasue a lot of the wrapping needs to be done at release time (for example: de-allocating memory), and that means that you no longer can do simple system calls that don't even need release notification AT ALL. syslets do work that way - they require some user memory - likely long-standing (100% sure for multi atom setup, maybe it can be optimized though) - if you do not want to allocate it explicitly - it is possible to have a wrapper. Currently generic example is following: allocate mem setup complex structure submit syscall wait syscall free mem And that allocate mem and free mem is a problem. It's not just a performance problem, it is a _complexity_ problem. It means that people have to track things that they are NOT AT ALL INTERESTED IN! I proposed a way to hide allocation - it is simple, but you've cut it. I can create another one without special per-thread thing - handle = async_init(); async_stat(handle, path, stat); async_cleanup(); // not needed, since will be freed on exit automatically Another one is to preallocate set of atoms in __attribute((contructor)) function. There are really a lot of possible ways - _I_ can use the first one with explicit operations, others likely can not - so I _ask_ about how should it look like. So, describe how exactly _you_ think it should be implemented with its pros and cons, so that systemn could be adopted without trying to mind-read of what is simple and good or complex and really bad. So I think that a good implementation just does everything up-front, and doesn't _need_ a user buffer that is live over longer periods, except for the actual results. Exactly because the whole alloc/teardown is nasty. And I think a good implementation doesn't need wrapping in user space to be useful - at *least* not wrapping at completion time, which is the really difficult one (since, by definition, in an async world completion is separated from the initial submit() event, and with kernel-only threads you actually want to *avoid* having to do user code after the operation completed). So where is a problem? I proposed already three ways to do the thing - user will not even know about something happend. You did not comment on anyone, instead you handwaving with talks about how in theory something should be similar to. What exactly do _you_ expect from interface? I suspect Ingo's thing can do that. But I also suspect (nay, _know_, from this discussion), that you didn't even think of the problems. That is another problem - you think you know something, but you fail to prove that. I can work with explicit structure allocation/deallocation/setup - you do not want that - so I ask you about your opinion, and instead of getting an answer I receive theoretical word-fall about how perfect interface should look like. You only need to have one function call without ever thinking bout freeing? I proposed _two_ ways to that. You can live with explicit init/cleanup (opt) code? There is another one. So please decribe your vision of interface with details, so that it could be think about or/and implemented. Linus -- Evgeniy Polyakov - 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] i386: adjustments to page table dump during oops (v4)
- make the page table contents printing PAE capable
- make sure the address stored in current-thread.cr2 is unmodified
from what was read from CR2
- don't call oops_may_print() multiple times, when one time suffices
- print pte even in highpte case, as long as the pte page isn't in
actually in high memory (which is specifically the case for all page
tables covering kernel space)
(Changes to v3: Use sizeof()*2 rather than the suggested sizeof()*4 for
printing width, use fixed 16-nibble width for PAE, and also apply the
max_low_pfn range check to the middle level lookup on PAE.)
Signed-off-by: Jan Beulich [EMAIL PROTECTED]
--- linux-2.6.20/arch/i386/mm/fault.c 2007-02-04 19:44:54.0 +0100
+++ 2.6.20-i386-page-fault-dump/arch/i386/mm/fault.c2007-02-14
08:31:38.0 +0100
@@ -20,6 +20,7 @@
#include linux/tty.h
#include linux/vt_kern.h /* For unblank_screen() */
#include linux/highmem.h
+#include linux/bootmem.h /* for max_low_pfn */
#include linux/module.h
#include linux/kprobes.h
#include linux/uaccess.h
@@ -327,7 +328,6 @@ fastcall void __kprobes do_page_fault(st
struct mm_struct *mm;
struct vm_area_struct * vma;
unsigned long address;
- unsigned long page;
int write, si_code;
/* get the address */
@@ -538,7 +538,9 @@ no_context:
bust_spinlocks(1);
if (oops_may_print()) {
- #ifdef CONFIG_X86_PAE
+ __typeof__(pte_val(__pte(0))) page;
+
+#ifdef CONFIG_X86_PAE
if (error_code 16) {
pte_t *pte = lookup_address(address);
@@ -547,7 +549,7 @@ no_context:
NX-protected page - exploit attempt?
(uid: %d)\n, current-uid);
}
- #endif
+#endif
if (address PAGE_SIZE)
printk(KERN_ALERT BUG: unable to handle kernel NULL
pointer dereference);
@@ -557,25 +559,38 @@ no_context:
printk( at virtual address %08lx\n,address);
printk(KERN_ALERT printing eip:\n);
printk(%08lx\n, regs-eip);
- }
- page = read_cr3();
- page = ((unsigned long *) __va(page))[address 22];
- if (oops_may_print())
+
+ page = read_cr3();
+ page = ((__typeof__(page) *) __va(page))[address
PGDIR_SHIFT];
+#ifdef CONFIG_X86_PAE
+ printk(KERN_ALERT *pdpt = %016Lx\n, page);
+ if ((page PAGE_SHIFT) max_low_pfn
+page _PAGE_PRESENT) {
+ page = PAGE_MASK;
+ page = ((__typeof__(page) *) __va(page))[(address
PMD_SHIFT)
+
(PTRS_PER_PMD - 1)];
+ printk(KERN_ALERT *pde = %016Lx\n, page);
+ page = ~_PAGE_NX;
+ }
+#else
printk(KERN_ALERT *pde = %08lx\n, page);
- /*
-* We must not directly access the pte in the highpte
-* case, the page table might be allocated in highmem.
-* And lets rather not kmap-atomic the pte, just in case
-* it's allocated already.
-*/
-#ifndef CONFIG_HIGHPTE
- if ((page 1) oops_may_print()) {
- page = PAGE_MASK;
- address = 0x003ff000;
- page = ((unsigned long *) __va(page))[address PAGE_SHIFT];
- printk(KERN_ALERT *pte = %08lx\n, page);
- }
#endif
+
+ /*
+* We must not directly access the pte in the highpte
+* case if the page table is located in highmem.
+* And let's rather not kmap-atomic the pte, just in case
+* it's allocated already.
+*/
+ if ((page PAGE_SHIFT) max_low_pfn
+(page _PAGE_PRESENT)) {
+ page = PAGE_MASK;
+ page = ((__typeof__(page) *) __va(page))[(address
PAGE_SHIFT)
+
(PTRS_PER_PTE - 1)];
+ printk(KERN_ALERT *pte = %0*Lx\n, sizeof(page)*2,
(u64)page);
+ }
+ }
+
tsk-thread.cr2 = address;
tsk-thread.trap_no = 14;
tsk-thread.error_code = error_code;
-
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: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 21:48 -0800, v j wrote: We only get crap because no one here yet knows how to interpret proprietary modules loaded into the kernel. The proprietary modules where only a tiny wrapper is linux-specific and the rest is cross-platform are in a grey area, yes. But your modules, written specifically for linux but distributed as binary-only, are specifically what the people choosing the GPL want to avoid. They are a derivative work, and are, as such, illegal under the GPL. As stated by multiple other people, please consult a lawyer if you want to be nasty. Or just play by the rules. Xav - 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: GPL vs non-GPL device drivers
I'll say that again, for everyone else who is reading this: the GPL makes it really clear that extensions to a GPL work are required to be distributed under the terms of the GPL. All this junk about derivative works is just the legal jargon used to implement the intent of the GPL. You can argue that a particular extension isn't a derivative work if you want, but you can't argue with the intent.. cause it is written in plain english. I don't think it was the intent of the GPL that if you want to make drivers for a GPL'd operating system, you must make the drivers GPL'd. That seems like precisely the sort of software-patent oligopoly (owning every way to do a particular thing) that the GPL was intended to combat. I quote from Stallman: Nobody is trying to patent specific programs; that isn't allowed, but nobody would bother even if it was allowed. A patent covering one specific program would not really matter to anyone. The reason why these patents create an issue is that they're not about specific programs, they're much more general. Each of these patents covers an idea that you might use in implementing various different programs, that lots of different programmers might use, might put into the programs that they are writing. And that's what makes them obstacles and dangers to software development activity. This is precisely what every Linux driver is a derivative work of my work is saying. It is totally counter to the spirit and intent of the GPL. Every time you say, that's a derivative work and you need to follow the rules, that's one less situation where you can say, this is fair use in an analogous case with a commercial work. If closed source drivers are against the spirit of the GPL, then it's not fair use to tinker with a commercial work to get it to work with your hardware. Most certainly the spirit of the GPL is that it's fair use to tinker with a work to get it to work on your hardware. Is it not fair use to share that with other licensees of the original work? Should Microsoft be able to prevent me from distributing patches to Windows that fix bugs or add features? It is so funny that the GPL community is succumbing to the same desire to expand intellectual property rights to get more control over their work that they condemn in the closed source world. The open source community should be trying to expand fair use, not expand derivative works. In addition, it is quite clear legally that if you take only what every attempt to perform the same function must take, you are not a derivative work. That is, if you are writing a Linux driver for an X1950 graphics card, you can take what any Linux driver for an X1950 graphics could would reasonably need to take. (See, among other cases, Lexmark. v. Static Controls.) A copyright is not a patent, you can only own something if there are multiple equally good ways to do it and you claim *one* of them. DS - 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: PROBLEM: 2.6.19.1 Oops while doing Disk IO + playing sound, 2.6.20 too
On Fri 16-02-07 00:01:32, Frank Hartmann wrote: Jan Kara [EMAIL PROTECTED] writes: On Thu 15-02-07 00:33:31, Frank Hartmann wrote: Jan Kara [EMAIL PROTECTED] writes: Yes I see some correlation. Again it seems there is a problem with buffers attached to a page which got truncated but Private flag of the page stayed. It's probably not important but just out of curiosity - do you have CONFIG_LBD (large block device) set? I'd just like to verify that page_bufs was NULL when it was passed to walk_page_buffers(). fantasio:~/tmp/linux-2.6.20$ fgrep CONFIG_LBD .config # CONFIG_LBD is not set OK, thanks. Then I'm slightly confused as the offset 0x2d in struct buffer_head is somewhere in b_assoc_buffers which is never dereferenced. Can you run gdb on vmlinux from the 2.6.20 kernel and send me the output of 'disass walk_page_buffers'? Thanks. I seem to missunderstand you. I am running now 2.6.19., so do not wonder. In your mail from February 11, you sent an oops from 2.6.20 kernel. That's why I was interested in the 2.6.20 kernel's vmlinux. But 2.6.19.2 would be interesting too. Could you help out, what I do wrong? fantasio:/home/frank/tmp/linux-2.6.19.2# gdb vmlinux GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...(no debugging symbols found) Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) disass walk_page_buffers No symbol table is loaded. Use the file command. Sorry, I forgot you have to have the kernel compiled with the CONFIG_DEBUG_INFO option (in the kernel hacking section) for the above to work. It is enough to get the vmlinux file from such compilation. You don't have to actually run the kernel... Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - 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: GPL vs non-GPL device drivers
On Fri, 2007-02-16 at 03:19 -0500, [EMAIL PROTECTED] wrote: [...] Actually, the *real* reason embedded systems end up using old versions is much simpler. ACK. They start developing their code on release 2.X.Y, and they keep their code out-of-tree. Then, when they come up for air, and it's at 2.X.(Y+15), they discover that we weren't kidding when we shipped stable_api_nonsense.txt, and since their code isn't in the tree, they have to do all the API cleanup themselves, because no flock of nit-picking kernel janitor monkeys swarmed over their code and magically fixed it up for them. Actually it is questionable for product development in a commercial environment (especially in the embedded world where you usually have a quite defined hardware and software on your device) if one actually wants that - think of the if it's not broken, don't fix it reason. And unless Y+15 has some *very* compelling reasons to move forward, just sticking at Y suddenly starts looking very good, because watching somebody else's kernel janitor monkeys fix your code is fairly cheap, but paying your own kernel janitor monkeys gets expensive really fast It depends on the *very* compelling reason if it is easier/cheaper to a) fix the problem in the old kernel, b) backport something or c) forward port the own drivers/changes. And that decision depends on lots of factors (and company-internal bureaucracy with the QA department may not be the least important). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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: [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core
On Friday, 16 February 2007 09:12, Srivatsa Vaddagiri wrote:
On Fri, Feb 16, 2007 at 12:46:17PM +0530, Srivatsa Vaddagiri wrote:
frozen. The only exception is cleaning up of per-cpu threads (which is
not possible with processes frozen - if we can find a way to make that
possible, then everything can be done in CPU_DEAD).
How abt a patch like below?
--- process.c.org 2007-02-16 13:38:39.0 +0530
+++ process.c 2007-02-16 13:38:59.0 +0530
@@ -47,7 +47,7 @@ void refrigerator(void)
recalc_sigpending(); /* We sent fake signal, clean it up */
spin_unlock_irq(current-sighand-siglock);
- while (frozen(current)) {
+ while (frozen(current) !kthread_should_stop()) {
current-state = TASK_UNINTERRUPTIBLE;
schedule();
}
This should let us do kthread_stop() in CPU_DEAD itself (while processes
are frozen)? That would allow us to do everything from CPU_DEAD itself
(and not have CPU_DEAD_KILL_THREADS).
Well, the suspend code has been developed with the assumption that frozen
threads stay frozen until _we_ let them thaw by calling thaw_processes(). I'm
a bit afraid of this change.
Greetings,
Rafael
-
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: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 18:36 -0600, Scott Preece wrote: if the drivers are for devices proprietary to their hardware, then they have no real value to anyone else. And the drivers MIGHT contain information useful to their actual competitors. Don't you feel like a contradiction in those two sentences ? :) Xav - 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: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation
On Thu, 15 February 2007 23:59:14 +0100, Juan Piernas Canovas wrote: Actually, the version of DualFS for Linux 2.4.19 implements a cleaner. In our case, the cleaner is not really a problem because there is not too much to clean (the meta-data device only contains meta-data blocks which are 5-6% of the file system blocks; you do not have to move data blocks). That sounds as if you have not hit the interesting cases yet. Fun starts when your device is near-full and you have a write-intensive workload. In your case, that would be metadata-write-intensive. For one, this is where write performance of log-structured filesystems usually goes down the drain. And worse, it is where the cleaner can run into a deadlock. Being good where log-structured filesystems usually are horrible is a challenge. And I'm sure many people are more interested in those performance number than in the ones you shine at. :) Jörn -- Joern's library part 14: http://www.sandpile.org/ - 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] fb: SM501 framebuffer driver (#5)
Driver for the Silicon Motion SM501 multifunction device
framebuffer subsystem.
This driver supports both the CRT and LCD panel heads,
with some simple acceleration for the cursor plotting
and support for screen panning. There is no current
support for bitblt/drawing engines, which should be
added at a later date.
This has been tested on a number of configurations,
including PCI and generic-bus, on PPC, ARM and SH4
Signed-off-by: Ben Dooks [EMAIL PROTECTED]
Signed-off-by: Vincent Sanders [EMAIL PROTECTED]
diff -urpN -X ../dontdiff linux-2.6.20/drivers/video/Kconfig
linux-2.6.20-sm501-3/drivers/video/Kconfig
--- linux-2.6.20/drivers/video/Kconfig 2007-02-04 18:44:54.0 +
+++ linux-2.6.20-sm501-3/drivers/video/Kconfig 2007-02-13 15:35:34.0
+
@@ -1600,6 +1600,24 @@ config FB_S3C2410_DEBUG
Turn on debugging messages. Note that you can set/unset at run time
through sysfs
+config FB_SM501
+ tristate Silicon Motion SM501 framebuffer support
+ depends on FB MFD_SM501
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ Frame buffer driver for the CRT and LCD controllers in the Silicon
+ Motion SM501.
+
+ This driver is also available as a module ( = code which can be
+ inserted and removed from the running kernel whenever you want). The
+ module will be called sm501fb. If you want to compile it as a module,
+ say M here and read file:Documentation/modules.txt.
+
+ If unsure, say N.
+
+
config FB_PNX4008_DUM
tristate Display Update Module support on Philips PNX4008 board
depends on FB ARCH_PNX4008
diff -urpN -X ../dontdiff linux-2.6.20/drivers/video/Makefile
linux-2.6.20-sm501-3/drivers/video/Makefile
--- linux-2.6.20/drivers/video/Makefile 2007-02-04 18:44:54.0 +
+++ linux-2.6.20-sm501-3/drivers/video/Makefile 2007-02-13 15:35:34.0
+
@@ -100,6 +100,7 @@ obj-$(CONFIG_FB_S3C2410) += s3c2410fb.
obj-$(CONFIG_FB_PNX4008_DUM) += pnx4008/
obj-$(CONFIG_FB_PNX4008_DUM_RGB) += pnx4008/
obj-$(CONFIG_FB_IBM_GXT4500) += gxt4500.o
+obj-$(CONFIG_FB_SM501)+= sm501fb.o
# Platform or fallback drivers go here
obj-$(CONFIG_FB_VESA) += vesafb.o
diff -urpN -X ../dontdiff linux-2.6.20/drivers/video/sm501fb.c
linux-2.6.20-sm501-3/drivers/video/sm501fb.c
--- linux-2.6.20/drivers/video/sm501fb.c1970-01-01 01:00:00.0
+0100
+++ linux-2.6.20-sm501-3/drivers/video/sm501fb.c2007-02-16
09:33:07.0 +
@@ -0,0 +1,1786 @@
+/* linux/drivers/video/sm501fb.c
+ *
+ * Copyright (c) 2006 Simtec Electronics
+ * Vincent Sanders [EMAIL PROTECTED]
+ * Ben Dooks [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Framebuffer driver for the Silicon Motion SM501
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/string.h
+#include linux/mm.h
+#include linux/tty.h
+#include linux/slab.h
+#include linux/delay.h
+#include linux/fb.h
+#include linux/init.h
+#include linux/vmalloc.h
+#include linux/dma-mapping.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/wait.h
+#include linux/platform_device.h
+#include linux/clk.h
+
+#include asm/io.h
+#include asm/uaccess.h
+#include asm/div64.h
+
+#ifdef CONFIG_PM
+#include linux/pm.h
+#endif
+
+#include linux/sm501.h
+#include linux/sm501-regs.h
+
+#define NR_PALETTE 256
+
+enum sm501_controller {
+ HEAD_CRT= 0,
+ HEAD_PANEL = 1,
+};
+
+/* SM501 memory adress */
+struct sm501_mem {
+ unsigned longsize;
+ unsigned longsm_addr;
+ void __iomem*k_addr;
+};
+
+/* private data that is shared between all frambuffers* */
+struct sm501fb_info {
+ struct device *dev;
+ struct fb_info *fb[2]; /* fb info for both heads */
+ struct resource *fbmem_res; /* framebuffer resource */
+ struct resource *regs_res; /* registers resource */
+ struct sm501_platdata_fb *pdata;/* our platform data */
+
+ int irq;
+ int swap_endian; /* set to swap rgb=bgr */
+ void __iomem*regs; /* remapped registers */
+ void __iomem*fbmem; /* remapped framebuffer */
+ size_t fbmem_len; /* length of remapped region */
+};
+
+/* per-framebuffer private data */
+struct sm501fb_par {
+ u32 pseudo_palette[16];
+
+ enum sm501_controllerhead;
+ struct sm501_mem cursor;
+ struct sm501_mem screen;
+ struct fb_opsops;
+
+ void*store_fb;
Re: GPL vs non-GPL device drivers
On Thu, 15 Feb 2007 22:25:12 PST, v j said: It's written in black and white, in the license. Please point me to where it says I cannot load proprietary modules in the Kernel. Nobody can point you there, because it doesn't say that anywhere. What you do to *your* kernel is *your* business. The question is what the code you *distribute* to *other* people does. It's perfectly legal to load proprietary modules into the kernel. The open question is whether you're allowed to ship a proprietary module to somebody else. And that will depend in *great* detail on *exactly* what your module does, what code it uses, and how it does it. As others have pointed out, NVidia and ATI think they're in an OK spot with the way *they* do *their* module, while many embedded companies, shipping a much different product, have almost unanimously given in rather than risk a court fight about the GPL. Of course, most companies will cave in and license rather than fight a patent troll as well - so you *really* need to discuss *your* case with a clueful lawyer. pgpSj8wrFTxNn.pgp Description: PGP signature
2.6.20.git regression: 'PCI: add the sysfs driver name to all modules' causes hard hang on boot
Greetings, Per $subject, git.yesterday hangs hard on boot here. A git bisect fingered the commit below, which I verified via git bisect reset; git revert -n 725522b5453dd680412f2b6463a988e4fd148757, after which box boots fine. (well, I hope I verified... i'm git-ignorant) commit 725522b5453dd680412f2b6463a988e4fd148757 Author: Greg Kroah-Hartman [EMAIL PROTECTED] Date: Mon Jan 15 11:50:02 2007 -0800 PCI: add the sysfs driver name to all modules This adds the module name to all PCI drivers, if they are built into the kernel or not. It will show up in /sys/modules/MODULE_NAME/drivers/ It also fixes up the IDE core, which was calling __pci_register_driver() directly. Cc: Kay Sievers [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] :04 04 a97900b3284ece0d5f1a3eed372f98c5cb4b10d3 4d1f3045dc379f0eb7064fd05dd311625c090ef3 M drivers :04 04 434c6fa20bd7f9acadb2c6d4a8dfe19a05fe8ea2 9f8ef888fe4050d8cab7333955a6eafb0d2f0fba M include Kernel messages: [0.781850] ipmi message handler version 39.1 [0.786438] ipmi device interface [0.789973] IPMI System Interface driver. hangs here on bad kernel [0.805356] ipmi_si: Unable to find any System Interface(s) [0.811224] IPMI Watchdog: driver initialized gzipped up config attached. -Mike config.gz Description: GNU Zip compressed data
Re: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 18:36 -0600, Scott Preece wrote: [...] Note that it is possible that what vj said is strictly true. IF the product they ship is non-modifiable, then it's hard to argue that anyone else could maintain it. And if the drivers are for devices The GPL has no special handling for that case. proprietary to their hardware, then they have no real value to anyone else. And the drivers MIGHT contain information useful to their actual competitors. I have no knowledge as to whether those conditions And that may a (BTW invalid) reason for lots of companies but you probably won't find an exception in the GPLv2 for this. And if you infringe on others' patents, you should probably look elsewhere for a solution of that problem. actually apply. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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: [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core
On Fri, Feb 16, 2007 at 10:29:20AM +0100, Rafael J. Wysocki wrote: Well, the suspend code has been developed with the assumption that frozen threads stay frozen until _we_ let them thaw by calling thaw_processes(). I'm a bit afraid of this change. Note that only kernel threads created thr' kthread_create are allowed to exit like this from the refrigerator, that too only when (kthread_stop_info.k == current). So all other threads should be unaffected because of this change. -- Regards, vatsa - 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: GPL vs non-GPL device drivers
I quote from Stallman: Nobody is trying to patent specific programs; that isn't allowed, but nobody would bother even if it was allowed. A patent covering one specific program would not really matter to anyone. The reason why these patents create an issue is that they're not about specific programs, they're much more general. Each of these patents covers an idea that you might use in implementing various different programs, that lots of different programmers might use, might put into the programs that they are writing. And that's what makes them obstacles and dangers to software development activity. What are you talking about? This is not about software patents AT ALL. Not one person is claiming they have a patent on whatever it is that V J's company is putting out (especially since we have no idea what that might be). Patents != copyright. Software patents: This super cool red button idea is mine. If you make a red button, you have to give me money. Copyright: This code is mine. You can't copy my code without my permission. GPL: You can copy my code all you want, BUT if you add on to it and give out the results, you have to give out your code too! Your argument might have some sort of merit, but I gave up trying to work through it. Stop confusing patents and copyright and try again. Joshua Simmons - 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/
2.6.20-ck1
This patchset is designed to improve system responsiveness and interactivity. It is configurable to any workload but the default -ck patch is aimed at the desktop and -cks is available with more emphasis on serverspace. Apply to 2.6.20 http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.20/2.6.20-ck1/patch-2.6.20-ck1.bz2 or server version http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.20/2.6.20-ck1/patch-2.6.20-cks1.bz2 web: http://kernel.kolivas.org all patches: http://www.kernel.org/pub/linux/kernel/people/ck/patches/ Split patches available. Full patchlist: sched-staircase-17.patch sched-staircase17_interactive_tunable.patch sched-staircase17_compute_tunable.patch sched-range.patch sched-iso-4.7.patch track_mutexes-1.patch sched-idleprio-1.1.patch sched-limit_policy_changes.patch sched-make_softirqd_batch.patch cfq-ioprio_inherit_rt_class.patch cfq-iso_idleprio_ionice.patch hz-default_1000.patch hz-no_default_250.patch sched-add-above-background-load-function.patch mm-swap_prefetch-34.patch mm-convert_swappiness_to_mapped.patch mm-lots_watermark.diff mm-kswapd_inherit_prio-1.patch mm-prio_dependant_scan-2.patch mm-background_scan-2.patch mm-idleprio_prio.patch mm-filesize_dependant_lru_cache_add.patch kconfig-expose_vmsplit_option.patch ck1-version.patch このカーネルは立派だと思いますよ -- -ck pgpfSNro5KUKs.pgp Description: PGP signature
Re: [Linux-fbdev-devel] [PATCH] fb: SM501 framebuffer driver (#5)
On Fri, Feb 16, 2007 at 09:50:45AM +, Ben Dooks wrote:
Driver for the Silicon Motion SM501 multifunction device
framebuffer subsystem.
This driver supports both the CRT and LCD panel heads,
with some simple acceleration for the cursor plotting
and support for screen panning. There is no current
support for bitblt/drawing engines, which should be
added at a later date.
This has been tested on a number of configurations,
including PCI and generic-bus, on PPC, ARM and SH4
The difference between this and the previous version is
that the checks in pan display have been removed, as per
James' suggestion:
diff -urpN -X ../dontdiff linux-2.6.20-sm501-2/drivers/video/sm501fb.c
linux-2.6.20-sm501-3/drivers/video/sm501fb.c
--- linux-2.6.20-sm501-2/drivers/video/sm501fb.c2007-02-13
19:14:47.0 +
+++ linux-2.6.20-sm501-3/drivers/video/sm501fb.c2007-02-16
09:33:07.0 +
@@ -496,23 +496,6 @@ static void sm501fb_set_par_geometry(str
writel(reg, base + SM501_OFF_DC_V_SYNC);
}
-/* sm501fb_validate_pan
- *
- * check panning on a var
-*/
-
-static inline int sm501fb_validate_pan(struct fb_var_screeninfo *var)
-{
- if (var-xoffset 0 || var-yoffset 0)
- return 0;
-
- if (var-xoffset (var-xres_virtual - var-xres) ||
- var-yoffset (var-yres_virtual - var-yres))
- return 0;
-
- return 1;
-}
-
/* sm501fb_pan_crt
*
* pan the CRT display output within an virtual framebuffer
@@ -527,9 +510,6 @@ static int sm501fb_pan_crt(struct fb_var
unsigned long reg;
unsigned long xoffs;
- if (!sm501fb_validate_pan(var))
- return -EINVAL;
-
xoffs = var-xoffset * bytes_pixel;
reg = readl(fbi-regs + SM501_DC_CRT_CONTROL);
@@ -558,9 +538,6 @@ static int sm501fb_pan_pnl(struct fb_var
struct sm501fb_info *fbi = par-info;
unsigned long reg;
- if (!sm501fb_validate_pan(var))
- return -EINVAL;
-
reg = var-xoffset | (var-xres_virtual 16);
writel(reg, fbi-regs + SM501_DC_PANEL_FB_WIDTH);
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
-
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: GPL vs non-GPL device drivers
Xavier Bestel wrote: On Thu, 2007-02-15 at 21:48 -0800, v j wrote: We only get crap because no one here yet knows how to interpret proprietary modules loaded into the kernel. The proprietary modules where only a tiny wrapper is linux-specific and the rest is cross-platform are in a grey area, yes. But your modules, written specifically for linux but distributed as binary-only, are specifically what the people choosing the GPL want to avoid. They are a derivative work, and are, as such, illegal under the GPL. If they are a derivative work, they are illegal under the GPL. However, it is not clear that their being written specifically *for* Linux is sufficient to make them derivative works *of* Linux. Jon Kåre - 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: kbuild question
Hi, On Thu, 15 Feb 2007, Kumar Gala wrote: I was wondering if there was some way to make a Kconfig menu either be just a menu or a choice depending on another bool being set or not. What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I want it so you can only select on option, however if CONFIG_ONLY_HAVE_ONE is not set you should be able to select multiple options. Could you please be more specific about the problem you're trying to solve, instead of how you're trying to solve it? A real example would help a lot to understand the actual problem. bye, Roman - 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: GPL vs non-GPL device drivers
On Thu, 15 Feb 2007 22:25:12 PST, v j said: (Damn, hit send too soon) No, just that the trend is disturbing. If enough Kernel Developers choose to write their Software in a way that prevents others from using it freely, then that is troubling. Especially when these Kernel Developers are substituting existing interfaces in the Kernel with ones that are NEW and require specific licenses. Again - there's nothing stopping you from fixing *your* copy to work any way you want. I freely admit that *my* kernel is quite often running code that I don't want to release under the GPL (usually because it's too ghastly for submission in-tree :) - but that's OK, because I don't let that sort of code escape. :) There's nothing stopping you from shipping a GPL'ed patch that fixes it the way you want it to work, to any and all who want to install your patch. I've done that too - posted provably incorrect, but works for me patches for bugs I've hit. Once in a while, my provably incorrect assertion even turns out to be itself incorrect. ;) There's nothing stopping you from shipping GPL'ed code that lies about its MODULE_LICENSE. But if you're shipping *non*-GPL'ed code that does that sort of thing, you demonstrate that you *knew* what the author thought about derivative works. So you really have 4 options: 0) Don't ship code. Send a board and a spec sheet to Greg KH. :) 1) Release it properly under the GPL. 2) Consult a lawyer, and decide to risk shipping it non-GPL. 3) Rebase your code so it runs on a *BSD or vxworks or other OS where your code's licence and the OS license are known to be compatible. Pick one, and live with it. pgp507L7p5QVH.pgp Description: PGP signature
Re: GPL vs non-GPL device drivers
David Schwartz wrote: Most certainly the spirit of the GPL is that it's fair use to tinker with a work to get it to work on your hardware. Is it not fair use to share that with other licensees of the original work? Should Microsoft be able to prevent me from distributing patches to Windows that fix bugs or add features? Yes they can, since you have (most likely) breached the contract! To fix a bug in Windows you will have to de-assemble their code (if you are not on their pay-role, of course) and that is explicitly forbidden. You are in no way allowed to read how Windows does things. Or you may just have made random changes and it happens to work, I still don't think they would like it (what other thing may happened by that patch?) Richard Knutsson - 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: GPL vs non-GPL device drivers
On Thu, 2007-02-15 at 22:25 -0800, v j wrote: [...] No, just that the trend is disturbing. If enough Kernel Developers choose to write their Software in a way that prevents others from using it freely, then that is troubling. Especially when these Kernel You can use it freely - your definitions of free and closed are broken (at least on LKML). Developers are substituting existing interfaces in the Kernel with ones that are NEW and require specific licenses. That claimed specific license is the very same license that the rest of the kernel has since day 1. So what? Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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] lockdep: annotate BLKPG_DEL_PARTITION
=
[ INFO: possible recursive locking detected ]
2.6.19-1.2909.fc7 #1
-
anaconda/587 is trying to acquire lock:
(bdev-bd_mutex){--..}, at: [c05fb380] mutex_lock+0x21/0x24
but task is already holding lock:
(bdev-bd_mutex){--..}, at: [c05fb380] mutex_lock+0x21/0x24
other info that might help us debug this:
1 lock held by anaconda/587:
#0: (bdev-bd_mutex){--..}, at: [c05fb380] mutex_lock+0x21/0x24
stack backtrace:
[c0405812] show_trace_log_lvl+0x1a/0x2f
[c0405db2] show_trace+0x12/0x14
[c0405e36] dump_stack+0x16/0x18
[c043bd84] __lock_acquire+0x116/0xa09
[c043c960] lock_acquire+0x56/0x6f
[c05fb1fa] __mutex_lock_slowpath+0xe5/0x24a
[c05fb380] mutex_lock+0x21/0x24
[c04d82fb] blkdev_ioctl+0x600/0x76d
[c04946b1] block_ioctl+0x1b/0x1f
[c047ed5a] do_ioctl+0x22/0x68
[c047eff2] vfs_ioctl+0x252/0x265
[c047f04e] sys_ioctl+0x49/0x63
[c0404070] syscall_call+0x7/0xb
Annotate BLKPG_DEL_PARTITION's bd_mutex locking and add a little comment
clarifying the bd_mutex locking, because I confused myself and initially
thought the lock order was wrong too.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
---
block/ioctl.c |2 +-
fs/block_dev.c |7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
Index: linux-2.6.20.noarch/block/ioctl.c
===
--- linux-2.6.20.noarch.orig/block/ioctl.c
+++ linux-2.6.20.noarch/block/ioctl.c
@@ -82,7 +82,7 @@ static int blkpg_ioctl(struct block_devi
fsync_bdev(bdevp);
invalidate_bdev(bdevp, 0);
- mutex_lock(bdev-bd_mutex);
+ mutex_lock_nested(bdev-bd_mutex, 1);
delete_partition(disk, part);
mutex_unlock(bdev-bd_mutex);
mutex_unlock(bdevp-bd_mutex);
Index: linux-2.6.20.noarch/fs/block_dev.c
===
--- linux-2.6.20.noarch.orig/fs/block_dev.c
+++ linux-2.6.20.noarch/fs/block_dev.c
@@ -1101,6 +1101,13 @@ static int __blkdev_get(struct block_dev
int for_part);
static int __blkdev_put(struct block_device *bdev, int for_part);
+/*
+ * bd_mutex locking:
+ *
+ * mutex_lock(part-bd_mutex)
+ *mutex_lock_nested(whole-bd_mutex, 1)
+ */
+
static int do_open(struct block_device *bdev, struct file *file, int for_part)
{
struct module *owner = NULL;
-
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: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation
JE == Jörn Engel [EMAIL PROTECTED] writes: JE Being good where log-structured filesystems usually are horrible JE is a challenge. And I'm sure many people are more interested in JE those performance number than in the ones you shine at. :) Anything that helps performance when untarring source trees is interesting to me. I wish DualFS a lot of luck, and I hope to get to play with it. /Benny - 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: 2.6.20-rt5 Oops on boot [-rt8 OK]
* Rui Nuno Capela [EMAIL PROTECTED] wrote: Rui Nuno Capela (me) wrote: I have terrible news: 2.6.20-rt5 does not boot at all on a couple machines I was brave enough to try -- a [EMAIL PROTECTED] SMP/HT desktop, and a Core2 Duo [EMAIL PROTECTED] laptop. For the first case I could capture the following dump via serial console: ... News are that 2.6.20-rt8 got it all back to business :) great! The fix is from Michal/Clark/Steve. Ingo - 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 Cobalt button interface driver support
Hi,
Thank you for your comments.
On Thu, 15 Feb 2007 23:09:43 -0500
Dmitry Torokhov [EMAIL PROTECTED] wrote:
On Thursday 15 February 2007 22:36, Yoichi Yuasa wrote:
Hi,
This patch adds support for the back panel buttons on Cobalt server.
It's tested on the Cobalt Qube2.
Hi,
Thank you for your patch. Couple of comments:
+
+ button++;
+ }
+
+ mod_timer(buttons_timer, jiffies + HZ / BUTTONS_POLL_FREQUENCY);
May I suggest using msecs_to_jiffies() to avoid direct computations on HZ?
OK, I updated it.
+
+ bdev-input = input;
+ bdev-reg = ioremap(res-start, res-end - res-start + 1);
+ dev_set_drvdata(pdev-dev, bdev);
+
+ setup_timer(buttons_timer, handle_buttons, (unsigned long)bdev);
+ mod_timer(buttons_timer, jiffies + HZ / BUTTONS_POLL_FREQUENCY);
Please implement cobalt_buttons_open() and cobalt_buttons_close() methods
and start/stop timer from there - there is no point in polling hardware
if noone is listening to the events.
I updated it too.
+static int __devexit cobalt_buttons_remove(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct buttons_dev *bdev = dev_get_drvdata(dev);
+
+ del_timer(buttons_timer);
del_timer_sync? Is there any possibility it may run SMP?
Cobalt server doesn't support SMP. but there is no problem.
I updated it.
+static void __exit cobalt_buttons_exit(void)
+{
+ platform_driver_unregister(cobalt_buttons_driver);
You are not allowed to unregister statically allocated devices -
if there are references left and your module goes away then
these references become invalid and kernel goes boom.
Please convert to platform_device_alloc/platform_device_add.
I updated it.
Is there a point of moving platform device creation code into
platform-specific code? Is there a possibility of this driver
being used elsewhere?
No it isn't.
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -pruN -X mips/Documentation/dontdiff mips-orig/drivers/input/misc/Kconfig
mips/drivers/input/misc/Kconfig
--- mips-orig/drivers/input/misc/Kconfig2007-02-14 15:35:30.566862000
+0900
+++ mips/drivers/input/misc/Kconfig 2007-02-15 17:20:28.721985250 +0900
@@ -89,4 +89,10 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config INPUT_COBALT_BTNS
+ tristate Cobalt button interface
+ depends on MIPS_COBALT
+ help
+ Say Y here if you want to support MIPS Cobalt button interface.
+
endif
diff -pruN -X mips/Documentation/dontdiff mips-orig/drivers/input/misc/Makefile
mips/drivers/input/misc/Makefile
--- mips-orig/drivers/input/misc/Makefile 2007-02-14 15:35:30.566862000
+0900
+++ mips/drivers/input/misc/Makefile2007-02-15 11:55:30.856042500 +0900
@@ -12,3 +12,4 @@ obj-$(CONFIG_INPUT_WISTRON_BTNS) += wist
obj-$(CONFIG_INPUT_ATLAS_BTNS) += atlas_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
diff -pruN -X mips/Documentation/dontdiff
mips-orig/drivers/input/misc/cobalt_btns.c mips/drivers/input/misc/cobalt_btns.c
--- mips-orig/drivers/input/misc/cobalt_btns.c 1970-01-01 09:00:00.0
+0900
+++ mips/drivers/input/misc/cobalt_btns.c 2007-02-16 16:09:48.857365000
+0900
@@ -0,0 +1,233 @@
+/*
+ * Cobalt button interface driver.
+ *
+ * Copyright (C) 2007 Yoichi Yuasa [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+#include linux/init.h
+#include linux/input.h
+#include linux/ioport.h
+#include linux/miscdevice.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/jiffies.h
+#include linux/timer.h
+
+#include asm/param.h
+
+#define BUTTONS_POLL_INTERVAL 30 /* msec */
+#define BUTTONS_COUNT_THRESHOLD3
+#define BUTTONS_STATUS_MASK0xfe00
+
+struct buttons_dev {
+ struct input_dev *input;
+ void __iomem *reg;
+};
+
+struct buttons_map {
+ uint32_tmask;
+ int keycode;
+ int count;
+};
+
+static struct buttons_map buttons_map[] = {
+ { 0x0200,
Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Dan Hecht wrote: On 02/15/2007 11:04 PM, Jeremy Fitzhardinge wrote: HZ - I'm assuming dynticks will appear in the short term, and this will become moot Doesn't Xen send any non-blocked domain a 100hz alarm implicitly, without anyway for the guest to disable it? I guess you'll have to break kernel/hypervisor compatibility if you want dynticks? The timer VIRQ will generate events at a fixed 100Hz (which can be masked, like any other event), but you can also ask for a timer event at a particular time. We do this already for tickless idle. J - 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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Ian Campbell [EMAIL PROTECTED] writes: On Fri, 2007-02-16 at 00:33 -0700, Eric W. Biederman wrote: I know there actually has been some work to get kexec actually working under Xen but I don't know where that has gone. kexec/kdump works with Xen 3.0.4 but it's a dom0 only thing so it doesn't appear in this patchset. Ok but we still need to get the failure to user space for domU instead of trying what works on real hardware and failing. Eric - 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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
On Fri, 2007-02-16 at 00:33 -0700, Eric W. Biederman wrote: I know there actually has been some work to get kexec actually working under Xen but I don't know where that has gone. kexec/kdump works with Xen 3.0.4 but it's a dom0 only thing so it doesn't appear in this patchset. Ian. - 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 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Eric W. Biederman wrote: Ian Campbell [EMAIL PROTECTED] writes: On Fri, 2007-02-16 at 00:33 -0700, Eric W. Biederman wrote: I know there actually has been some work to get kexec actually working under Xen but I don't know where that has gone. kexec/kdump works with Xen 3.0.4 but it's a dom0 only thing so it doesn't appear in this patchset. Ok but we still need to get the failure to user space for domU instead of trying what works on real hardware and failing. Eric Acked-by: Zachary Amsden [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: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
On 02/16/2007 12:05 AM, Jeremy Fitzhardinge wrote: Dan Hecht wrote: On 02/15/2007 11:04 PM, Jeremy Fitzhardinge wrote: HZ - I'm assuming dynticks will appear in the short term, and this will become moot Doesn't Xen send any non-blocked domain a 100hz alarm implicitly, without anyway for the guest to disable it? I guess you'll have to break kernel/hypervisor compatibility if you want dynticks? The timer VIRQ will generate events at a fixed 100Hz (which can be masked, like any other event), but you can also ask for a timer event at a particular time. We do this already for tickless idle. J Hmm? I thought the periodic timer and one-shot timer both generate the same VIRQ. So, how can you mask one without masking the other? The tickless idle works since the block hypercall disables the periodic timer. But for dynticks (aka NO_HZ), you'll need to mask the periodic timer (even for a running vcpu), while keeping the one-shot timer unmasked. I don't think Xen provides an interface to do that. Dan - 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 07/21] Xen-paravirt: remove ctor for pgd cache
On 2/16/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Remove the ctor for the pgd cache. There's no point in having the cache machinery do this via an indirect call when all pgd are freed in the one place anyway. The reason we have slab constructors and destructors is to _avoid_ reinitializing every time we allocate an object. AFAICT your changing the code now to do _more_ work than before, so is there some other reason why you want to do this than avoiding an indirect call? - 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 04/21] Xen-paravirt: ===================================================================
Subject? description? On Thu, Feb 15, 2007 at 06:24:53PM -0800, Jeremy Fitzhardinge wrote: -static void vmi_set_pte_present(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte) +static void vmi_set_pte_present(struct mm_struct *mm, u32 addr, pte_t *ptep, pte_t pte) And what good is that change anyways? unsigned long is the usual style for addresses. -Andi - 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 12/21] Xen-paravirt: Allocate and free vmalloc areas
It's for populating the pagetable in a vmalloc area. There's magic in If the lazy setup doesn't work for you you can always call vmalloc_sync() early. -Andi - 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 07/21] Xen-paravirt: remove ctor for pgd cache
Pekka Enberg wrote: On 2/16/07, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Remove the ctor for the pgd cache. There's no point in having the cache machinery do this via an indirect call when all pgd are freed in the one place anyway. The reason we have slab constructors and destructors is to _avoid_ reinitializing every time we allocate an object. AFAICT your changing the code now to do _more_ work than before, so is there some other reason why you want to do this than avoiding an indirect call? Sometimes it is better for the caches to initialise an object immediately, but in this case I think it is better to use the slab ctor because it is very unlikely to use many cachelines immediately anyway. It would be nice to put the why in the changelogs, rather than what. Not everyone wants to go through the whole patchset to decipher why Xen possibly needs something. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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 14/21] Xen-paravirt: Add XEN config options and disableunsupported config options.
On Fri, 16 Feb 2007 02:00:39 -0800 Christian Limpach [EMAIL PROTECTED] wrote: Jeremy Fitzhardinge wrote: Andrew Morton wrote: On Thu, 15 Feb 2007 22:14:45 -0800 Dan Hecht [EMAIL PROTECTED] wrote: config PREEMPT bool Preemptible Kernel (Low-Latency Desktop) + depends on !XEN help This option reduces the latency of the kernel by making all kernel code (that is not executing in a critical section) Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. In which case that preempt_disable() I spotted is wrong-and-unneeded. Why doesn't Xen work with preemption?? I've forgotten the details. Ian? Keir? Steven? Maybe it can be done. With CONFIG_PREEMPT, we can have preempted threads reference machine addresses across save/restore. After restore, these machine addresses will be incorrect. It would help if you could define the terms save/restore and machine addresses. One can guess, but there are probably subtleties here.. Are the places where the domU code references machine addresses splattered all over the code? If not, they can just be wrapped with preempt_disable/preempt_enable? - 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: [Xen-devel] Re: [patch 14/21] Xen-paravirt: Add XEN config options and disable unsupported config options.
Keir Fraser wrote: On 16/2/07 07:25, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Oh, so that's why it doesn't break when CONFIG_PREEMPT=y. In which case that preempt_disable() I spotted is wrong-and-unneeded. Why doesn't Xen work with preemption?? I've forgotten the details. Ian? Keir? Steven? Maybe it can be done. It breaks guest save/restore for us currently because threads can be sleeping with machine addresses in local storage (registers, stack). There are a few ways to achieve an acceptable solution: 1. Put processes in the freezer when we suspend. This should avoid any thread being in a critical section with machine addresses in its hand. We haven't yet investigated the performance impact of freezing processes, particularly on the downtime of live relocation. 2. Allow CONFIG_PREEMPT to be compiled in, but disable it at runtime. We could do this by, for example, reserving a bit in preempt_count() so that most preemption checks do not touch any more cache lines. I guess it would need a bit of fixing up (e.g., so that in_atomic() would not be always asserted). Even better for us would be to allow switching between involuntary and voluntary preemption at runtime. It looks as though the hook points for these two techniques are not usually compiled in at the same time, however. Doesn't stop_machine_run already take care of getting you out of all kernel threads? So you can only be sleeping, not preempted, in which case, this might not be an issue? Zach - 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: kernel porting query
On Fri, 2007-02-16 at 07:46 +0530, Rick Brown wrote: Your quoting style sucks. I fixed it by hand. [...] 1) Can any one please shed some light on precisely and exactly what are differences in different boards for which we need to port linux? On Fri, 2007-02-16 at 09:48 +0530, Ajay Singh (ajaysi) wrote: The differences depends on the boards ... Mostly if they belong to the same family the differences could be mainly in the peripherials ... Interrupt mappings... Serial interface ... Memory sizes (if differnet boards have different memory sizes) ... Sometimes some devices may be moved to some other locations in the memory map (Look at memory map of your SoC on your board). You may have different boot loaders (or none at all). You also may have different storage media like FlashRAM, IDE, network, for boot loader/kernel/root filesystem. They may have different sizes and it makes a little difference for your requirements in the toolchain if you have 4MB or 1GB to boot your system from. All that kind of information can be found in a BSP (board support package). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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: [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core
On Friday, 16 February 2007 10:59, Srivatsa Vaddagiri wrote: On Fri, Feb 16, 2007 at 10:29:20AM +0100, Rafael J. Wysocki wrote: Well, the suspend code has been developed with the assumption that frozen threads stay frozen until _we_ let them thaw by calling thaw_processes(). I'm a bit afraid of this change. Note that only kernel threads created thr' kthread_create are allowed to exit like this from the refrigerator, that too only when (kthread_stop_info.k == current). So all other threads should be unaffected because of this change. Yes, that's why I said a bit. ;-) - 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: somebody dropped a (warning) bomb
Bodo Eggert [EMAIL PROTECTED] writes: Sergei Organov [EMAIL PROTECTED] wrote: Linus Torvalds [EMAIL PROTECTED] writes: [...] Using signed chars for strings is wrong in most countries on earth. It was wrong when the first IBM PC came out in 1981, and creating a compiler in 1987 defaulting to signed char is a sure sign of originating from an isolated country and knowing nothing about this planet. Maybe I'm wrong, but wasn't it the case that C had no signed char type that time, so char had to be abused for the tiny signed integer? Using signed chars in comparisons is especially wrong, and casting each char to unsigned before comparing them is likely to be forgotten. If we start talking about the C language, my opinion is that it's C problem that it allows numeric comparison of char variables at all. If one actually needs to compare alphabetic characters numerically, he should first cast to required integer type. Unsigned character strings are useless because there is no such thing as char(-23), and if these strings weren't casted to signed inside all IO functions, they wouldn't work correctly. Didn't you swap signed and unsigned by mistake in this phrase? Or are you indeed think that using unsigned char* for strings is useless? Only because many programmers don't compare chars, most programs will work outside the USA. Comparison of characters being numeric is not a very good property of the C language. I repeat: Thanks to using signed chars, the programs only work /by/ /accident/! Promoting the use of signed char strings is promoting bugs and endangering the stability of all our systems. You should stop this bullshit now, instead of increasing the pile. Where did you see I promoted using of singed char strings?! If you don't like the fact that in C language characters are char, strings are char*, and the sign of char is implementation-defined, please argue with the C committee, not with me. Or use -funsigned-char to get dialect of C that fits your requirements better. -- Sergei. - 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: GPL vs non-GPL device drivers
On Feb 16 2007 10:44, Jon K Hellan wrote: Xavier Bestel wrote: On Thu, 2007-02-15 at 21:48 -0800, v j wrote: We only get crap because no one here yet knows how to interpret proprietary modules loaded into the kernel. The proprietary modules where only a tiny wrapper is linux-specific and the rest is cross-platform are in a grey area, yes. But your modules, written specifically for linux but distributed as binary-only, are specifically what the people choosing the GPL want to avoid. They are a derivative work, and are, as such, illegal under the GPL. If they are a derivative work, they are illegal under the GPL. However, it is not clear that their being written specifically *for* Linux is sufficient to make them derivative works *of* Linux. Who knows, perhaps there's a public domain interface that wraps linux kernel function calls into bsd functions, so you can always successfully argue the source code is not only for Linux. However, I think that precompiled .ko files are _much more_ tied to Linux (in short, supporting your point) plus a specific architecture. Jan -- - 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: GPL vs non-GPL device drivers
What are you talking about? This is not about software patents AT ALL. Yes, it is. The difference between a copyright and a patent is this simple -- a copyright protects the one particular way you chose to do something and a patent protects every possible way of doing the same thing (or employing the same method). Not one person is claiming they have a patent on whatever it is that V J's company is putting out (especially since we have no idea what that might be). Patents != copyright. That's exactly what they're doing. Knowing only the *function* of his program, they are claiming it must obey their licensing terms. They have no idea exactly how he chose to implement that function, but claim they must own it anyway. Software patents: This super cool red button idea is mine. If you make a red button, you have to give me money. Copyright: This code is mine. You can't copy my code without my permission. Not quite. Copyright is: This particular implementation is mine, but you are free to implement any idea any *other* way you want. You simply can't implement an idea precisely the way I did it, but all ideas are open to you. GPL: You can copy my code all you want, BUT if you add on to it and give out the results, you have to give out your code too! But that's not what's happening here. A Linux driver for graphics cards based on the X1950 chipset is not an add on to Linux. It's an idea and a function all on its own. Your argument might have some sort of merit, but I gave up trying to work through it. Stop confusing patents and copyright and try again. I do not have them confused. You cannot own any practical way to make a driver for Linux under copyright, only patent gives you that kind of power. You can, of course, own the particular way I chose to make a Linux driver, out of many other equally-good ways. DS - 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: GPL vs non-GPL device drivers
On Fri, 2007-02-16 at 03:42 -0800, David Schwartz wrote: [...] Not quite. Copyright is: This particular implementation is mine, but you are free to implement any idea any *other* way you want. You simply can't implement an idea precisely the way I did it, but all ideas are open to you. Actually you can legally (at least/even with author's rights hereover). But it will be very hard to convince a judge and/or lawyers that you didn't actually copy it. And the question is moot anyways since it is extremely unlikely you end up with the same implementation for the same problem (unless the problem is small/simple/trivial enough like binary search in a sorted array on int's). Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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] another id for cp2101 driver
This patch adds another usb id to the cp2101. It seems to work well.
Please apply, thanks.
Signed-off-by: Pozsar Balazs [EMAIL PROTECTED]
diff -Naurd a/drivers/usb/serial/cp2101.c b/drivers/usb/serial/cp2101.c
--- a/drivers/usb/serial/cp2101.c 2006-07-15 21:00:43.0 +0200
+++ b/drivers/usb/serial/cp2101.c 2007-02-16 12:41:47.0 +0100
@@ -65,6 +65,7 @@
{ USB_DEVICE(0x10C4, 0x813D) }, /* Burnside Telecom Deskmobile */
{ USB_DEVICE(0x10C4, 0x815E) }, /* Helicomm IP-Link 1220-DVM */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
+ { USB_DEVICE(0x10C5, 0xEA61) }, /* Silicon Labs MobiData GPRS USB Modem
*/
{ USB_DEVICE(0x16D6, 0x0001) }, /* Jablotron serial interface */
{ } /* Terminating Entry */
};
--
pozsy
-
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] aio: fix kernel bug when page is temporally busy
Zach Brown wrote:
It will not return until kiocbSetKicked() is called,
and that is only called from kick_iocb().
There is no test or wait of Kicked in considered
for (;;) aio_write() loop.
Zach Brown wrote:
The proposed patch does not crate this bug if any.
Right, and I said that in the mail you're quoting.
...
You're introducing other bugs with the patch.
Could you list other introduced bugs?
It is interesting that I've not seen any EIOCBQUEUED returned
to aio_run_iocb() during 5 hours aiostress running.
What arguments are you running aio-stress with? -EIOCBQUEUED is only
used for O_DIRECT
I wrote in the vary first mail that the panic is appearing in
random write O_DIRECT aio-stress running. Other aio-stress modes
where tested after patching as well.
and then only in certain circumstances.
Looking closely into sources we can see that
EIOCBQUEUED never may be returned to aio_run_iocb().
include/linux/aio.h says
* If ki_retry returns -EIOCBRETRY ...
Could you point source line which returns -EIOCBRETRY?
Leonid
-Original Message-
From: Zach Brown [mailto:[EMAIL PROTECTED]
Sent: Friday, February 16, 2007 3:01 AM
To: Ananiev, Leonid I
Cc: Ken Chen; [EMAIL PROTECTED]; Andrew Morton;
linux-kernel@vger.kernel.org; linux-aio; Chris Mason
Subject: Re: [PATCH] aio: fix kernel bug when page is temporally busy
On Feb 15, 2007, at 3:32 PM, Ananiev, Leonid I wrote:
If EIOCBRETRY then generic_file_aio_write() will be recalled for the
same iocb.
Only if kick_iocb() is called. It won't be called if i_i_p2_r() was
the only thing to return -EIOCBRETRY.
It is not need to call kick_iocb()
for generic_file_aio_write() calling.
It is recalled without any wakeup waiting:
for (;;) {
ret = filp-f_op-aio_write(kiocb, iov, 1,
kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
wait_on_retry_sync_kiocb(kiocb);
}
Note: wait_on_retry_sync_kiocb() does not wait.
Yes it does. It will not return until kiocbSetKicked() is called,
and that is only called from kick_iocb().
It overwrites -EIOCBQUEUED
Do you mean that there is one more kernel bug which
overwrites -EIOCBQUEUED by any errno or number of bytes and this
new value is returned to caller as an IO result
while IO is not finished yet.
The proposed patch does not crate this bug if any.
Right, and I said that in the mail you're quoting.
It actually fixes a kernel panic bag when iocb.users count becomes
incorrect. The bag Kernel BUG at fs/aio.c:509 is there because
aio_run_iocb() have not a chance to differ real EIO and
EIO which is actually means EAGAYN or EIOCBRETRY.
Yes, I understand the bug you're trying to fix. You're introducing
other bugs with the patch. It will not be merged.
It is interesting that I've not seen any EIOCBQUEUED returned
to aio_run_iocb() during 5 hours aiostress running.
What arguments are you running aio-stress with? -EIOCBQUEUED is only
used for O_DIRECT, and then only in certain circumstances.
- z
-
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] MAINTAINERS: mark framebuffer as Orphan
On Thu, Feb 15, 2007 at 03:05:26PM -0800, Randy Dunlap wrote: On Thu, 15 Feb 2007 22:26:10 + (GMT) James Simmons wrote: I wouldn't say it orphan. I just can't spend 8 hours a day on it. Alot of patches have been flowing into the layer. So would you like to leave it as Maintained or change it to Odd Fixes? (Maintained = a maintainer) From the MAINTAINTERS file: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. Odd Fixes: It has a maintainer but they don't have time to do much other than throw the odd patch in. See below.. Orphan: No current maintainer [but maybe you could take the role as you write your new code]. Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that. ... If you start doing this, there are a lot more entries that need to be changed... Which of Supported/Maintained/Odd Fixes is written doesn't matter in practice. What matters is that James' email address gets into the entry so that patches and bug reports reach him. James' work is definitely no below the average of entries marked as Maintained. ~Randy cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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 05/11] syslets: core code
* Linus Torvalds [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007, Linus Torvalds wrote: So I think that a good implementation just does everything up-front, and doesn't _need_ a user buffer that is live over longer periods, except for the actual results. Exactly because the whole alloc/teardown is nasty. Btw, this doesn't necessarily mean not supporting multiple atoms at all. I think the batching of async things is potentially a great idea. I think it's quite workable for open+fstat kind of things, and I agree that it can solve other things too (the socket+bind+connect+sendmsg+rcv kind of complex setup things). But I suspect that if we just said: - we limit these atom sequences to just linear sequences of max n ops - we read them all in in a single go at startup we actually avoid several nasty issues. Not just the memory allocation issue in user space (now it's perfectly ok to build up a sequence of ops in temporary memory and throw it away once it's been submitted), but also issues like the 32-bit vs 64-bit compatibility stuff (the compat handlers would just convert it when they do the initial copying, and then the actual run-time wouldn't care about user-level pointers having different sizes etc). Would it make the interface less cool? Yeah. Would it limit it to just a few linked system calls (to avoid memory allocation issues in the kernel)? Yes again. But it would simplify a lot of the interface issues. It would _also_ allow the sys_aio_read() function to build up its *own* set of atoms in kernel space to actually do the read, and there would be no impact of the actual run-time wanting to read stuff from user space. Again - it's actually the same issue as with the compat system call: by making the interfaces do things up-front rather than dynamically, it becomes more static, but also easier to do interface translations. You can translate into any arbitrary internal format _once_, and be done with it. I dunno. [ hm. I again wrote a pretty long email for you to read. Darn! ] regarding the API - i share most of your concerns, and it's all a function of how widely we want to push this into user-space. My initial thought was for syslets to be used by glibc as small, secure kernel-side 'syscall plugins' mainly - so that it can do things like 'POSIX AIO signal notifications' (which are madness in terms of performance, but which applications rely on) /without/ having to burden the kernel-side AIO with such requirements: glibc just adds an enclosing sys_kill() to the syslet and it will do the proper signal notification, asynchronously. (and of course syslets can be used for the Tux type of performance sillinesses as well ;-) So a sane user API (all used at the glibc level, not at application level) would use simple syslets, while more broken ones would have to use longer ones - but nobody would have the burden of having to synchronize back to the issuer context. Natural selection will gravitate application use towards the APIs with the shorter syslets. (at least so i hope) In this model syslets arent really user-programmable entities but rather small plugins available to glibc to build up more complex, more innovative (or just more broken) APIs than what the kernel wants to provide - without putting any true new ABI dependency on the kernel, other than the already existing syscall ABIs. But if we'd like glibc to provide this to applications in some sort of standardized /programmable/ manner, with a wide range of atom selections (not directly coded syscall numbers, but rather as function pointers to actual glibc functions, which glibc could translate to syscall numbers, argument encodings, etc.), then i agree that doing the compat things and making it 32/64-bit agnostic (and much more) is pretty much a must. If 90% of this current job is finished then sorting those out will at least be another 90% of the work ;-) and actually this latter model scares me, and i think that model scared the hell out of you as well. But i really have no strong opinion about which one we want yet, without having walked the path. Somewhere inside me i'd of course like syslets to become a widely available interface - but my fear is that it might just not be 'human' enough to make sense - and we'd just not want to tie us down with an ABI that's not used. I dont want this to become another sys_sendfile - much talked about and _almost_ useful but in practice seldom used due to its programmability and utility limitations. OTOH, the syslet concept right now already looks very ubiquitous, and the main problem with AIO use in applications wasnt just even its broken API or its broken performance, but the fundamental lack of all Linux IO disciplines supporting AIO, and the lack of significantly parallel hardware. We have kaio that is centered around block drivers - then we have epoll that works best with networking, and
Re: somebody dropped a (warning) bomb
Bodo Eggert [EMAIL PROTECTED] writes: Sergei Organov [EMAIL PROTECTED] wrote: Linus Torvalds [EMAIL PROTECTED] writes: Exactly because char *by*definition* is indeterminate sign as far as something like strlen() is concerned. Thanks, I now understand that you either don't see the difference between indeterminate and implementation-defined in this context or consider it non-essential, so I think I've got your point. If you don't code for a specific compiler with specific settings, there is no implementation defining the signedness of char, and each part of the code using char* will be wrong unless it handles both cases correctly. The problem here is that due to historical reasons, there could be code out there that abuses char for signed char (not sure about unsigned char). Old code and old habits are rather persistent. Therefore it's either always wrong to call your char* function with char*, unsigned char* _and_ signed char unless you can guarantee not to overflow any of them, or it's always correct to call char* functions with any kind of these. How are you sure those who wrote foo(char*) agrees with your opinion or even understands all the involved issues? Off cause if you happen to code for specific compiler settings, one signedness of char will become real and one warning will be legit. And if pigs fly, they should wear googles to protect their eyes ... And if people were writing perfect portable code all the time, there would be no need for warnings in the first place... -- Sergei. - 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: bloc_til_ready in tty driver
Mockern napsal(a): What for is bloc_til_ready function in tty drivers? Most drivers waits for hardware to detect carrier and for closed callout. regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: GPL vs non-GPL device drivers
On Thu, Feb 15, 2007 at 04:38:41PM -0800, David Schwartz wrote: ... Just to be perfectly clear, it is an outrageous claim that *every* *possible* kernel module must be a derivative work of the kernel. Copyright *cannot* protect every possible way to accomplish a particular function (and a Linux driver for the X800 graphics chipset is a function). This is just your personal opinion. derivative work is a term with many grey areas. Does linking create a derivative work? Or including the code of one static inline function in your binary? There is no border everyone agrees on. And even judges in different jurisdictions might decide differently based on different copyright laws. Perhaps some module would be considered legal in the USA and Russia but illegal in Germany and China, or the other way round. Copyright can *only* protect the one possible way you chose to do something out of a large number of equally good possible ways. (See, for example, Lexmark v. Static Controls where courts held that Static Controls could take Lexmark's TLP software because that was the only practical way to make a compatible toner cartridge.) ... It's always funny seeing people making univeral claims only based on laws and court cases that have zero relevance for 95% of all people... DS cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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 3/4] ipmi: add pci remove handling
Am Donnerstag, 15. Februar 2007 schrieb Corey Minyard:
On Thu, Feb 15, 2007 at 02:27:45AM -0800, Andrew Morton wrote:
Judging from the patch headers you were working against 2.6.19, which is
most optimistic. Please always prepare and test patches against the
latest kernel.
Well, I had it applied against a 2.6.20 kernel, but I messed up the
testing of it. Sorry, my bad.
New patch...
Add pci_remove handling to the driver, so it will clean up if
the device is hot-removed.
Signed-off-by: Corey Minyard [EMAIL PROTECTED]
Index: linux-2.6.20/drivers/char/ipmi/ipmi_si_intf.c
===
--- linux-2.6.20.orig/drivers/char/ipmi/ipmi_si_intf.c
+++ linux-2.6.20/drivers/char/ipmi/ipmi_si_intf.c
@@ -2191,12 +2191,15 @@ static int __devinit ipmi_pci_probe(stru
info-irq_setup = std_irq_setup;
info-dev = pdev-dev;
+ pdev-dev.driver_data = info;
return try_smi_init(info);
}
static void __devexit ipmi_pci_remove(struct pci_dev *pdev)
{
+ struct smi_info *info = pdev-dev.driver_data;
+ cleanup_one_si(info);
}
Please use pci_{set,get}_drvdata() to access this field.
Greetings,
Eike
pgpZcQ9PcLVW1.pgp
Description: PGP signature
[PATCH] parport_pc: Fix parport_pc_probe_port section warning
WARNING: drivers/parport/parport_pc.o - Section mismatch: reference
to .init.text: from .text between 'parport_pc_probe_port' (at offset
0x14f7) and 'parport_pc_unregister_port'
parport_dma_probe() cannot be declared __devinit as it is called
from parport_pc_probe_port() which isn't.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/parport/parport_pc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.20-rc1.orig/drivers/parport/parport_pc.c 2006-12-17
16:08:05.0 +0100
+++ linux-2.6.20-rc1/drivers/parport/parport_pc.c 2006-12-17
17:36:47.0 +0100
@@ -1546,7 +1546,7 @@
}
#endif /* CONFIG_PARPORT_PC_SUPERIO */
-static int __devinit get_superio_dma (struct parport *p)
+static int get_superio_dma (struct parport *p)
{
int i=0;
while( (superios[i].io != p-base) (iNR_SUPERIOS))
@@ -2106,7 +2106,7 @@
/* --- DMA detection -- */
/* Only if chipset conforms to ECP ISA Interface Standard */
-static int __devinit programmable_dma_support (struct parport *p)
+static int programmable_dma_support (struct parport *p)
{
unsigned char oecr = inb (ECONTROL (p));
int dma;
@@ -2123,7 +2123,7 @@
return dma;
}
-static int __devinit parport_dma_probe (struct parport *p)
+static int parport_dma_probe (struct parport *p)
{
const struct parport_pc_private *priv = p-private_data;
if (priv-ecr)
--
Jean Delvare
-
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: GPL vs non-GPL device drivers
Not one person is claiming they have a patent on whatever it is that V J's company is putting out (especially since we have no idea what that might be). Patents != copyright. That's exactly what they're doing. Knowing only the *function* of his program, they are claiming it must obey their licensing terms. They have no idea exactly how he chose to implement that function, but claim they must own it anyway. They are not claiming ownership of his code. They are claiming ownership of THEIR code. V J is taking their code, adding on to it and selling the result. Without the GPL, V J cannot legally do this. With the GPL, he can legally do this IF he also gives out the complete source. I fail to see how anything you are saying absolves him of this requirement. Joshua Simmons - 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: GPL vs non-GPL device drivers
On Thu, Feb 15, 2007 at 12:04:26AM -0800, v j wrote: Ok so are thousands of others who are using Linux as their OS of choice in embedded systems. They are not doing this because they are eager to give back back. They are doing it because Linux provides compelling reasons for them to choose it. They could have very well chosen VxWorks or OSE too. They chose not to, but not because they were unwilling to be a parasite. Some people in the embedded world actually think having access to cooporating with thousands of other developers is a good thing. I like being able to ask questions and get feedback. I have contributed back some of my improvements, and the things I haven't are things I think would make the kernel's drivers worse for general case use (due to having a few bits of weirdness in our hardware), but anyone that wants the source with those changes can have it. Our older products which are running a closed source OS (well as far as the customers are concerned at least, since we have source and they don't) are eventually intended to move to linux as well. The support for the proprietary embedded OSs have in our experience been pathetic. Even when sent patches to fix bugs they don't make it in to the next release in many cases. No thanks. What keeps customers buying our products is that when there is a problem we fix it as quickly as we can using whatever resources it takes. It isn't really in having secret source code for some feature. It would be hard for a smallish company to come up with something so amazing that a larger company couldn't reimplement the same thing in a very short time if they thought it was useful. -- Len Sorensen - 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 05/11] syslets: core code
On Fri, Feb 16, 2007 at 01:28:06PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: OTOH, the syslet concept right now already looks very ubiquitous, and the main problem with AIO use in applications wasnt just even its broken API or its broken performance, but the fundamental lack of all Linux IO disciplines supporting AIO, and the lack of significantly parallel hardware. We have kaio that is centered around block drivers - then we have epoll that works best with networking, and inotify that deals with some (but not all) VFS events - but neither supports every IO and event disciple well, at once. My feeling is that /this/ is the main fundamental problem with AIO in general, not just its programmability limitations. That is quite dissapointing to hear when weekely released kevent can solve that problem already more than year ago - it was designed specially to support every possible notification types and does support file descriptor ones, VFS (dropped in current releases to reduce size) and tons of other including POSIX times, signals, own high-performance AIO (which was created as a a bit complex state machine over internals of page population code) and essentially everything one can ever imagine with quite a bit of code needed for new type. I was requested to add waiting for futex through kevent queue - that is quite simple task, but having complete lack of feedback and ignorance of the project even from people who asked about its features, it looks like there is no need for that at all. -- Evgeniy Polyakov - 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 0/4] coredump: core dump masking support v3
Hi, This patch series is version 3 of the core dump masking feature, which provides a per-process flag not to dump anonymous shared memory segments. In this version, /proc/pid/coredump_omit_anonymous_shared file is provided as an interface instead of the previous /proc/pid/core_flags. If you have written a non-zero value to the file, anonymous shared memory segments of the process not to be dumped. Another change of this version is removal of kernel.core_flags_enables sysctl which enables/disables core dump flags globally. The purpose of this sysctl is for the system administrator to force all anonymous memory to be dumped. But ulimit -c 0 breaks it. So this sysctl is not helpful for the current linux. This patch series can be applied against 2.6.20-mm1. The supported core file formats are ELF and ELF-FDPIC. ELF has been tested, but ELF-FDPIC has not been build and tested because I don't have the test environment. Background: Some software programs share huge memory among hundreds of processes. If a failure occurs on one of these processes, they can be signaled by a monitoring process to generate core files and restart the service. However, it can develop into a system-wide failure such as system slow down for a long time and disk space shortage because the total size of the core files is very huge! To avoid the above situation we can limit the core file size by setrlimit(2) or ulimit(1). But this method can lose important data such as stack because core dumping is terminated halfway. So I suggest keeping shared memory segments from being dumped for particular processes. Because the shared memory attached to processes is common in them, we don't need to dump the shared memory every time. Usage: Get all shared memory segments of pid 1234 not to dump: $ echo 1 /proc/1234/coredump_omit_anonymous_shared When a new process is created, the process inherits the flag status from its parent. It is useful to set the core dump flags before the program runs. For example: $ echo 1 /proc/self/coredump_omit_anonymous_shared $ ./some_program ChangeLog: v3: - remove `/proc/pid/core_flags' proc entry - add `/proc/pid/coredump_anonymous_shared' as a named flag - remove kernel.core_flags_enable sysctl parameter v2: http://groups.google.com/group/linux.kernel/browse_frm/thread/cb254465971d4a42/ http://groups.google.com/group/linux.kernel/browse_frm/thread/da78f2702e06fa11/ - rename `coremask' to `core_flags' - change `core_flags' member in mm_struct to a bit field next to `dumpable' - introduce a global spin lock to protect adjacent two bit fields (core_flags and dumpable) from race condition - fix a bug that the generated core file can be corrupted when core dumping and updating core_flags occur concurrently - add kernel.core_flags_enable sysctl parameter to enable/disable flags in /proc/pid/core_flags - support ELF-FDPIC binary format, but not tested v1: http://groups.google.com/group/linux.kernel/browse_frm/thread/1381fc54d716e3e6/ -- Hidehiro Kawai Hitachi, Ltd., Systems Development Laboratory E-mail: [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: [patch] mm: NUMA replicated pagecache
On Thu, Feb 15, 2007 at 06:29:29PM -0500, Lee Schermerhorn wrote: I've attached another patch that closes one race and fixes a context problem [irq/preemption state] in __unreplicate_page_range(). This makes the locking even uglier :-(. I get further with this patch. Boot all the way up and can run fine with page replication. However, I still get a NULL pcd in find_get_page_readonly() when attempting a highly parallel kernel build [16cpu/4node numa platform]. I'm still trying to track that down. OK, before you get further with your testing, I have done a rework. Sorry you had to wade through that last lot of uncommented spaghetti. This upcoming version should actually be a reasonable base to do testing and development on. Question about locking: looks like the pcache_descriptor members are protected by the tree_lock of the mapping, right? Yes. I figured that this would be cleanest and simplest for now. This locking model is retained in the rework. Nick - 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/
[BUG?] register_blkdev: failed to get major for device mapper
Hi, I can't bring up my machine with root LVM anymore using x86_64. The same machine from same kernel tree boots fine as x86. The error message is quoted in subject. The tree is at 86a71dbd3e81e8870d0f0e56b87875f57e58222b (for those not using git: somewhere after 2.6.20). Attached are my .config of x86 and x86_64 as well as dmesg of failed boot as captured via serial line. The only other report of this problem dates back to early 2005 (see http://lkml.org/lkml/2005/2/5/29) and was about 2.6.11-rc2-mm2. I successfully have 2.6.18-rc7-something on this machine as x86_64 so it worked in between. Any ideas? Greetings, Eike Linux version 2.6.20-siso1 ([EMAIL PROTECTED]) (gcc version 4.1.0 (SUSE Linux)) #7 SMP Fri Feb 16 11:08:53 CET 2007 Command line: root=/dev/system/root64 console=ttyS0,38400 console=tty0 vga=normal selinux=0 resume=/dev/system/swap splash=verbose showopts BIOS-provided physical RAM map: BIOS-e820: - 0009b000 (usable) BIOS-e820: 0009b000 - 000a (reserved) BIOS-e820: 000e9b60 - 0010 (reserved) BIOS-e820: 0010 - 7ffb (usable) BIOS-e820: 7ffb - 7ffbe000 (ACPI data) BIOS-e820: 7ffbe000 - 7ffe (ACPI NVS) BIOS-e820: 7ffe - 8000 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fef0 (reserved) BIOS-e820: ff70 - 0001 (reserved) end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP 000FB650, 0014 (r0 ACPIAM) ACPI: RSDT 7FFB, 0034 (r1 A M I OEMRSDT 3000627 MSFT 97) ACPI: FACP 7FFB0200, 0084 (r2 A M I OEMFACP 3000627 MSFT 97) ACPI: DSDT 7FFB0450, 7E04 (r1 A0350 A03500011 INTL 2002026) ACPI: FACS 7FFBE000, 0040 ACPI: APIC 7FFB0390, 0080 (r1 A M I OEMAPIC 3000627 MSFT 97) ACPI: MCFG 7FFB0410, 003C (r1 A M I OEMMCFG 3000627 MSFT 97) ACPI: OEMB 7FFBE040, 005B (r1 A M I AMI_OEM 3000627 MSFT 97) Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 155 0: 256 - 524208 Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x508 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Nosave address range: 0009b000 - 000a Nosave address range: 000a - 000ea000 Nosave address range: 000ea000 - 0010 Allocating PCI resources starting at 8800 (gap: 8000:7ec0) PERCPU: Allocating 33920 bytes of per cpu data Built 1 zonelists. Total pages: 512835 Kernel command line: root=/dev/system/root64 console=ttyS0,38400 console=tty0 vga=normal selinux=0 resume=/dev/system/swap splash=verbose s Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 1648 kB per task-struct memory footprint: 1680 bytes Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Checking aperture... Memory: 2036040k/2096832k available (2574k kernel code, 60004k reserved, 1582k data, 220k init) Calibrating delay using timer specific routine.. 6006.12 BogoMIPS (lpj=12012248) Mount-cache hash table entries: 256 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM1) Freeing SMP alternatives: 24k freed ACPI: Core revision 20070126 Using local APIC timer interrupts. result 12500430 Detected 12.500 MHz APIC timer. lockdep: not fixing up alternatives. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 6000.83 BogoMIPS (lpj=12001670) CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K
[PATCH] i810fb: Fix i810_check_params section mismatch
WARNING: drivers/video/i810/i810fb.o - Section mismatch: reference to .init.data: from .text between 'i810_check_params' (at offset 0x1123) and 'encode_fix' yres cannot be declared __devinitdata as it is used in i810_check_params(), which isn't __devinit. Signed-off-by: Jean Delvare [EMAIL PROTECTED] --- This patch was already sent on December 17th, 2006. drivers/video/i810/i810_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.20-rc1.orig/drivers/video/i810/i810_main.c2006-12-17 16:02:06.0 +0100 +++ linux-2.6.20-rc1/drivers/video/i810/i810_main.c 2006-12-17 16:04:01.0 +0100 @@ -142,7 +142,7 @@ static int vsync1 __devinitdata; static int vsync2 __devinitdata; static int xres __devinitdata; -static int yres __devinitdata; +static int yres; static int vyres __devinitdata; static int sync __devinitdata; static int extvga __devinitdata; -- Jean Delvare - 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] mm: NUMA replicated pagecache (rewrite) for 2.6.20
Page-based NUMA pagecache replication. This is a scheme for page replication replicates read-only pagecache pages opportunistically, at pagecache lookup time (at points where we know the page is being looked up for read only). The page will be replicated if it resides on a different node to what the requesting CPU is on. Also, the original page must meet some conditions: it must be clean, uptodate, not under writeback, and not have an elevated refcount or filesystem private data. However it is allowed to be mapped into pagetables. Replication is done at the pagecache level, where a replicated pagecache (inode,offset) key will have its radix-tree entry specially tagged, and its radix-tree page will be replaced with a descriptor. Most importantly, this descriptor has another radix-tree which is keyed by node. Writes into pagetables are caught by having a filemap_mkwrite function, which collapses the replication before proceeding. After collapsing the replication, all process page tables are unmapped, so that any processes mapping discarded pages will refault in the correct one. /proc/vmstat has nr_repl_pages, which is the number of _additional_ pages replicated, beyond the first. Status: Completely reworked and optimised. This is actually a reasonable design and implementation. - Data structures and conceptual state machine remain basically identical, however implementation is changed so much that I don't think it will be worth posting the incremental diff. - Fastpath (ie. look up a page, without replicating or collapsing it) performance is basically unchanged now. - Slowpath (replicating, unreplicating) still has some small locking inefficiencies (eg. we could use a rwlock downgrade). However I don't want to get fancy there, because with the lockless pagecache it should naturally become ideal. - This is achieved by using a bit in the radix-tree entry pointer to tell us whether a given offset is a page or a pcache_desc. One good point about this is that it can give us completely lockless lookups for both replicated and unreplicated case with lockless pagecache. - Also, gang lookup functions no longer perform a wild sweep looking for replicated pages to collapse, but precisely collapse those that are needed. - Proper error handling implemented. We never get into a situation where setting up a replication could result in a failure where we're unable to restore the unreplicated state. - Use __GFP_THISNODE | __GFP_NORETRY to allocate slave pages (thanks Lee) - Made CONFIG_urable. - Moved into its own file, with 6 hooks used by the core mm. Still not quite as nice as I would like (eg. get_unreplicated_page variants), but it's getting closer. It might be cleaner to simply completely reimplement those few changed lookup functions if CONFIG_REPLICATION. - Locking is generally much nicer, but again not perfect. - Some commenting. - Fixes several races (thanks Lee). - No longer uses -page_mkwrite, but hooks into mm/memory.c. This means all filesystems should now work. - Unconditionally wrprotects ptes when cleaning a file page, and the page fault unreplicating hook locks then dirties the page, which should actually be a real attempt at getting the locking right this time. I still need to think more about this. Todo: - A PG_replicated bit will optimise reclaim and remove the last requirement for PAGECACHE_TAG_REPLICATED and radix_tree_tag_get! I didn't think this could be done so optimally without any changes to the radix tree! Sweet. This is implemented and will be included in the next version (I want to give it further testing). - Again, no NUMA testing. However my per-CPU test patch is much closer to the NUMA code this time, so it's more likely to work. - Would like to be able to control replication via userspace, and maybe even internally to the kernel. - Ideally, reclaim might reclaim replicated pages preferentially, however I aim to be _minimally_ intrusive, and this conflicts with that. - Would like to replicate PagePrivate, but filesystem may dirty page via buffers. Could replicate regular file pagecache, I think. - Would be nice to promote a slave to master when reclaiming the master. This This should be quite easy: must transfer relevant flags, and only promote if !PagePrivate (which reclaim itself takes care of). - More correctness testing. - Eventually, have to look at playing nicely with migration. include/linux/fs.h |1 include/linux/mm.h |6 include/linux/mm_types.h |8 include/linux/mmzone.h |1 include/linux/radix-tree.h |4 init/main.c|1 lib/radix-tree.c |2 mm/Kconfig | 11 + mm/Makefile|1 mm/filemap.c | 132 ++--- mm/internal.h | 59 ++ mm/replication.c | 435 + mm/vmscan.c|8 mm/vmstat.c
[patch] mm: per-CPU replicated pagecache (for testing)
Trial the replicated pagecache on non-NUMA machines by doing per-CPU
replication. Actually there is a slight change in one algorithm because
there is no such thing as page_to_cpuid.
To minimise the code change, this just pretends smp_processor_id returns
a node id. Technically this will blow up if you have more CPUs than
MAX_NUMNODES.
mm/replication.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
Index: linux-2.6/mm/replication.c
===
--- linux-2.6.orig/mm/replication.c
+++ linux-2.6/mm/replication.c
@@ -98,9 +98,6 @@ static int should_replicate_pcache(struc
if (unlikely(PageSwapCache(page)))
return 0;
- if (nid == page_to_nid(page))
- return 0;
-
if (page_count(page) != 2 + page_mapcount(page))
return 0;
smp_rmb();
@@ -133,7 +130,7 @@ static int try_to_replicate_pcache(struc
if (!pcd)
goto out;
- page_node = page_to_nid(page);
+ page_node = smp_processor_id();
pcd-master = page;
node_set(page_node, pcd-nodes_present);
if (radix_tree_insert(pcd-page_tree, page_node, page))
@@ -143,7 +140,7 @@ static int try_to_replicate_pcache(struc
/* The non-racy check */
if (unlikely(!should_replicate_pcache(page, mapping, offset,
- numa_node_id(
+ smp_processor_id(
goto out_lock;
pslot = radix_tree_lookup_slot(mapping-page_tree, offset);
@@ -269,13 +266,18 @@ failed:
static void __remove_replicated_page(struct pcache_desc *pcd, struct page
*page,
struct address_space *mapping, unsigned long offset)
{
- int nid = page_to_nid(page);
+ int nid;
BUG_ON(page == pcd-master);
- /* XXX: page-mapping = NULL; ? */
- BUG_ON(!node_isset(nid, pcd-nodes_present));
- BUG_ON(radix_tree_delete(pcd-page_tree, nid) != page);
- node_clear(nid, pcd-nodes_present);
- __dec_zone_page_state(page, NR_REPL_PAGES);
+ for_each_node_mask(nid, pcd-nodes_present) {
+ /* XXX: page-mapping = NULL; ? */
+ if (radix_tree_lookup(pcd-page_tree, nid) != page)
+ continue;
+ BUG_ON(radix_tree_delete(pcd-page_tree, nid) != page);
+ node_clear(nid, pcd-nodes_present);
+ __dec_zone_page_state(page, NR_REPL_PAGES);
+ return;
+ }
+ BUG();
}
/*
@@ -309,8 +311,7 @@ static struct page *try_to_create_replic
{
struct page *repl_page;
- repl_page = alloc_pages_node(nid, mapping_gfp_mask(mapping) |
- __GFP_THISNODE | __GFP_NORETRY, 0);
+ repl_page = page_cache_alloc(mapping);
if (!repl_page)
return page; /* failed alloc, just return the master */
@@ -343,7 +344,7 @@ struct page * find_get_page_readonly(str
retry:
read_lock_irq(mapping-tree_lock);
- nid = numa_node_id();
+ nid = smp_processor_id();
page = radix_tree_lookup(mapping-page_tree, offset);
if (is_pcache_desc(page)) {
struct pcache_desc *pcd;
-
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 1/4] coredump: add an interface to control the core dump routine
This patch adds an interface to set/reset a flag which determines
anonymous shared memory segments should be dumped or not when a core
file is generated.
/proc/pid/coredump_omit_anonymous_shared file is provided to access
the flag. You can change the flag status for a particular process by
writing to or reading from the file.
The flag status is inherited to the child process when it is created.
The flag is stored into coredump_omit_anon_shared member of mm_struct,
which shares bytes with dumpable member because these two are adjacent
bit fields. In order to avoid write-write race between the two, we use
a global spin lock.
smp_wmb() at updating dumpable is removed because set_dumpable()
includes a pair of spin lock and unlock which has the effect of
memory barrier.
Signed-off-by: Hidehiro Kawai [EMAIL PROTECTED]
---
fs/exec.c | 10 ++--
fs/proc/base.c| 99
include/linux/sched.h | 33 +
kernel/fork.c |3 +
kernel/sys.c | 62 -
security/commoncap.c |2
security/dummy.c |2
7 files changed, 164 insertions(+), 47 deletions(-)
Index: linux-2.6.20-mm1/fs/proc/base.c
===
--- linux-2.6.20-mm1.orig/fs/proc/base.c
+++ linux-2.6.20-mm1/fs/proc/base.c
@@ -74,6 +74,7 @@
#include linux/poll.h
#include linux/nsproxy.h
#include linux/oom.h
+#include linux/elf.h
#include internal.h
/* NOTE:
@@ -1753,6 +1754,100 @@ static const struct inode_operations pro
#endif
+#if defined(USE_ELF_CORE_DUMP) defined(CONFIG_ELF_CORE)
+static ssize_t proc_coredump_omit_anon_shared_read(struct file *file,
+ char __user *buf,
+ size_t count,
+ loff_t *ppos)
+{
+ struct task_struct *task = get_proc_task(file-f_dentry-d_inode);
+ struct mm_struct *mm;
+ char buffer[PROC_NUMBUF];
+ size_t len;
+ loff_t __ppos = *ppos;
+ int ret;
+
+ ret = -ESRCH;
+ if (!task)
+ goto out_no_task;
+
+ ret = 0;
+ mm = get_task_mm(task);
+ if (!mm)
+ goto out_no_mm;
+
+ len = snprintf(buffer, sizeof(buffer), %u\n,
+ mm-coredump_omit_anon_shared);
+ if (__ppos = len)
+ goto out;
+ if (count len - __ppos)
+ count = len - __ppos;
+
+ ret = -EFAULT;
+ if (copy_to_user(buf, buffer + __ppos, count))
+ goto out;
+
+ ret = count;
+ *ppos = __ppos + count;
+
+ out:
+ mmput(mm);
+ out_no_mm:
+ put_task_struct(task);
+ out_no_task:
+ return ret;
+}
+
+static ssize_t proc_coredump_omit_anon_shared_write(struct file *file,
+ const char __user *buf,
+ size_t count,
+ loff_t *ppos)
+{
+ struct task_struct *task;
+ struct mm_struct *mm;
+ char buffer[PROC_NUMBUF], *end;
+ unsigned int val;
+ int ret;
+
+ ret = -EFAULT;
+ memset(buffer, 0, sizeof(buffer));
+ if (count sizeof(buffer) - 1)
+ count = sizeof(buffer) - 1;
+ if (copy_from_user(buffer, buf, count))
+ goto out_no_task;
+
+ ret = -EINVAL;
+ val = (unsigned int)simple_strtoul(buffer, end, 0);
+ if (*end == '\n')
+ end++;
+ if (end - buffer == 0)
+ goto out_no_task;
+
+ ret = -ESRCH;
+ task = get_proc_task(file-f_dentry-d_inode);
+ if (!task)
+ goto out_no_task;
+
+ ret = end - buffer;
+ mm = get_task_mm(task);
+ if (!mm)
+ goto out_no_mm;
+
+ set_coredump_omit_anon_shared(mm, (val != 0));
+
+ mmput(mm);
+ out_no_mm:
+ put_task_struct(task);
+ out_no_task:
+ return ret;
+}
+
+static struct file_operations proc_coredump_omit_anon_shared_operations = {
+ .read = proc_coredump_omit_anon_shared_read,
+ .write = proc_coredump_omit_anon_shared_write,
+};
+#endif
+
/*
* /proc/self:
*/
@@ -1972,6 +2067,10 @@ static struct pid_entry tgid_base_stuff[
#ifdef CONFIG_FAULT_INJECTION
REG(make-it-fail, S_IRUGO|S_IWUSR, fault_inject),
#endif
+#if defined(USE_ELF_CORE_DUMP) defined(CONFIG_ELF_CORE)
+ REG(coredump_omit_anonymous_shared, S_IRUGO|S_IWUSR,
+ coredump_omit_anon_shared),
+#endif
#ifdef CONFIG_TASK_IO_ACCOUNTING
INF(io, S_IRUGO, pid_io_accounting),
#endif
Index: linux-2.6.20-mm1/include/linux/sched.h
===
--- linux-2.6.20-mm1.orig/include/linux/sched.h
+++ linux-2.6.20-mm1/include/linux/sched.h
@@ -366,7 +366,13 @@ struct mm_struct {
[PATCH 2/4] coredump: ELF: enable to omit anonymous shared memory
This patch enables to omit anonymous shared memory from an ELF
formatted core file when it is generated.
Signed-off-by: Hidehiro Kawai [EMAIL PROTECTED]
---
fs/binfmt_elf.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
Index: linux-2.6.20-mm1/fs/binfmt_elf.c
===
--- linux-2.6.20-mm1.orig/fs/binfmt_elf.c
+++ linux-2.6.20-mm1/fs/binfmt_elf.c
@@ -1181,7 +1181,7 @@ static int dump_seek(struct file *file,
*
* I think we should skip something. But I am not sure how. H.J.
*/
-static int maydump(struct vm_area_struct *vma)
+static int maydump(struct vm_area_struct *vma, unsigned int omit_anon_shared)
{
/* The vma can be set up to tell us the answer directly. */
if (vma-vm_flags VM_ALWAYSDUMP)
@@ -1191,9 +1191,15 @@ static int maydump(struct vm_area_struct
if (vma-vm_flags (VM_IO | VM_RESERVED))
return 0;
- /* Dump shared memory only if mapped from an anonymous file. */
- if (vma-vm_flags VM_SHARED)
- return vma-vm_file-f_path.dentry-d_inode-i_nlink == 0;
+ /*
+* Dump shared memory only if mapped from an anonymous file and
+* /proc/pid/coredump_omit_anonymous_shared flag is not set.
+*/
+ if (vma-vm_flags VM_SHARED) {
+ if (vma-vm_file-f_path.dentry-d_inode-i_nlink)
+ return 0;
+ return omit_anon_shared == 0;
+ }
/* If it hasn't been written to, don't write it out */
if (!vma-anon_vma)
@@ -1491,6 +1497,7 @@ static int elf_core_dump(long signr, str
#endif
int thread_status_size = 0;
elf_addr_t *auxv;
+ unsigned int omit_anon_shared = 0;
/*
* We no longer stop all VM operations.
@@ -1629,6 +1636,7 @@ static int elf_core_dump(long signr, str
}
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
+ omit_anon_shared = current-mm-coredump_omit_anon_shared;
/* Write program headers for segments dump */
for (vma = first_vma(current, gate_vma); vma != NULL;
@@ -1642,7 +1650,7 @@ static int elf_core_dump(long signr, str
phdr.p_offset = offset;
phdr.p_vaddr = vma-vm_start;
phdr.p_paddr = 0;
- phdr.p_filesz = maydump(vma) ? sz : 0;
+ phdr.p_filesz = maydump(vma, omit_anon_shared) ? sz : 0;
phdr.p_memsz = sz;
offset += phdr.p_filesz;
phdr.p_flags = vma-vm_flags VM_READ ? PF_R : 0;
@@ -1685,7 +1693,7 @@ static int elf_core_dump(long signr, str
vma = next_vma(vma, gate_vma)) {
unsigned long addr;
- if (!maydump(vma))
+ if (!maydump(vma, omit_anon_shared))
continue;
for (addr = vma-vm_start;
-
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 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory
This patch enables to omit anonymous shared memory from an ELF-FDPIC
formatted core file when it is generated.
The debug messages from maydump() in fs/binfmt_elf_fdpic.c are changed
appropriately so that we can know what kind of memory segments are
dumped or not.
Signed-off-by: Hidehiro Kawai [EMAIL PROTECTED]
---
fs/binfmt_elf_fdpic.c | 37 +
1 files changed, 25 insertions(+), 12 deletions(-)
Index: linux-2.6.20-mm1/fs/binfmt_elf_fdpic.c
===
--- linux-2.6.20-mm1.orig/fs/binfmt_elf_fdpic.c
+++ linux-2.6.20-mm1/fs/binfmt_elf_fdpic.c
@@ -1168,7 +1168,7 @@ static int dump_seek(struct file *file,
*
* I think we should skip something. But I am not sure how. H.J.
*/
-static int maydump(struct vm_area_struct *vma)
+static int maydump(struct vm_area_struct *vma, unsigned int omit_anon_shared)
{
/* Do not dump I/O mapped devices or special mappings */
if (vma-vm_flags (VM_IO | VM_RESERVED)) {
@@ -1184,15 +1184,22 @@ static int maydump(struct vm_area_struct
return 0;
}
- /* Dump shared memory only if mapped from an anonymous file. */
+ /*
+* Dump shared memory only if mapped from an anonymous file and
+* /proc/pid/coredump_omit_anonymous_shared flag is not set.
+*/
if (vma-vm_flags VM_SHARED) {
- if (vma-vm_file-f_path.dentry-d_inode-i_nlink == 0) {
+ if (vma-vm_file-f_path.dentry-d_inode-i_nlink) {
kdcore(%08lx: %08lx: no (share), vma-vm_start,
vma-vm_flags);
+ return 0;
+ }
+ if (omit_anon_shared) {
+ kdcore(%08lx: %08lx: no (anon-share), vma-vm_start,
vma-vm_flags);
+ return 0;
+ } else {
+ kdcore(%08lx: %08lx: yes (anon-share), vma-vm_start,
vma-vm_flags);
return 1;
}
-
- kdcore(%08lx: %08lx: no (share), vma-vm_start,
vma-vm_flags);
- return 0;
}
#ifdef CONFIG_MMU
@@ -1444,14 +1451,15 @@ static int elf_dump_thread_status(long s
*/
#ifdef CONFIG_MMU
static int elf_fdpic_dump_segments(struct file *file, struct mm_struct *mm,
- size_t *size, unsigned long *limit)
+ size_t *size, unsigned long *limit,
+ unsigned int omit_anon_shared)
{
struct vm_area_struct *vma;
for (vma = current-mm-mmap; vma; vma = vma-vm_next) {
unsigned long addr;
- if (!maydump(vma))
+ if (!maydump(vma, omit_anon_shared))
continue;
for (addr = vma-vm_start;
@@ -1499,14 +1507,15 @@ end_coredump:
*/
#ifndef CONFIG_MMU
static int elf_fdpic_dump_segments(struct file *file, struct mm_struct *mm,
- size_t *size, unsigned long *limit)
+ size_t *size, unsigned long *limit,
+ unsigned int omit_anon_shared)
{
struct vm_list_struct *vml;
for (vml = current-mm-context.vmlist; vml; vml = vml-next) {
struct vm_area_struct *vma = vml-vma;
- if (!maydump(vma))
+ if (!maydump(vma, omit_anon_shared))
continue;
if ((*size += PAGE_SIZE) *limit)
@@ -1557,6 +1566,7 @@ static int elf_fdpic_core_dump(long sign
struct vm_list_struct *vml;
#endif
elf_addr_t *auxv;
+ unsigned int omit_anon_shared = 0;
/*
* We no longer stop all VM operations.
@@ -1694,6 +1704,8 @@ static int elf_fdpic_core_dump(long sign
/* Page-align dumped data */
dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
+ omit_anon_shared = current-mm-coredump_omit_anon_shared;
+
/* write program headers for segments dump */
for (
#ifdef CONFIG_MMU
@@ -1715,7 +1727,7 @@ static int elf_fdpic_core_dump(long sign
phdr.p_offset = offset;
phdr.p_vaddr = vma-vm_start;
phdr.p_paddr = 0;
- phdr.p_filesz = maydump(vma) ? sz : 0;
+ phdr.p_filesz = maydump(vma, omit_anon_shared) ? sz : 0;
phdr.p_memsz = sz;
offset += phdr.p_filesz;
phdr.p_flags = vma-vm_flags VM_READ ? PF_R : 0;
@@ -1749,7 +1761,8 @@ static int elf_fdpic_core_dump(long sign
DUMP_SEEK(dataoff);
- if (elf_fdpic_dump_segments(file, current-mm, size, limit) 0)
+ if (elf_fdpic_dump_segments(file, current-mm, size, limit,
+ omit_anon_shared) 0)
goto end_coredump;
#ifdef ELF_CORE_WRITE_EXTRA_DATA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
[PATCH 4/4] coredump: documentation for proc entry
This patch adds the documentation for /proc/pid/coredump_omit_anonymous_shared. Signed-off-by: Hidehiro Kawai [EMAIL PROTECTED] --- Documentation/filesystems/proc.txt | 38 +++ 1 files changed, 38 insertions(+) Index: linux-2.6.20-mm1/Documentation/filesystems/proc.txt === --- linux-2.6.20-mm1.orig/Documentation/filesystems/proc.txt +++ linux-2.6.20-mm1/Documentation/filesystems/proc.txt @@ -41,6 +41,7 @@ Table of Contents 2.11 /proc/sys/fs/mqueue - POSIX message queues filesystem 2.12 /proc/pid/oom_adj - Adjust the oom-killer score 2.13 /proc/pid/oom_score - Display current oom-killer score + 2.14 /proc/pid/coredump_omit_anonymous_shared - Core dump coordinator -- Preface @@ -1982,6 +1983,43 @@ This file can be used to check the curre any given pid. Use it together with /proc/pid/oom_adj to tune which process should be killed in an out-of-memory situation. +2.14 /proc/pid/coredump_omit_anonymous_shared - Core dump coordinator +- +When a process is dumped, all anonymous memory is written to a core file as +long as the size of the core file isn't limited. But sometimes we don't want +to dump some memory segments, for example, huge shared memory. + +The /proc/pid/coredump_omit_anonymous_shared is a flag which enables you to +omit anonymous shared memory segments from a core file when it is generated. +When the pid process is dumped, the core dump routine decides whether a +given memory segment should be dumped into a core file or not based on the +type of the memory segment and the flag. + +If you have written a non-zero value to this proc file, anonymous shared +memory segments are not dumped. There are three types of anonymous shared +memory: + + - IPC shared memory + - the memory segments created by mmap(2) with MAP_ANONYMOUS and MAP_SHARED +flags + - the memory segments created by mmap(2) with MAP_SHARED flag, and the +mapped file has already been unlinked + +Because current core dump routine doesn't distinguish these segments, you can +only choose either dumping all anonymous shared memory segments or not. + +If you don't want to dump all shared memory segments attached to pid 1234, +write 0 to the process's proc file. + + $ echo 1 /proc/1234/coredump_omit_anonymous_shared + +When a new process is created, the process inherits the flag status from its +parent. It is useful to set the flag before the program runs. +For example: + + $ echo 1 /proc/self/coredump_omit_anonymous_shared + $ ./some_program + -- Summary -- - 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: GPL vs non-GPL device drivers
On 2/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: As others have pointed out, NVidia and ATI think they're in an OK spot with the way *they* do *their* module, Man, your sentence is so vague here that I almost don't feel the need to correct you, almost. I don't think NVIDIA or ATI think they can get away with distributing a binary only kernel module because of any of the technical measures they take to seperate themselves from the kernel code.. That's done for good technical reasons, they ship *BSD drivers too. I think the reason why they feel safe that no-one will sue them (and no company wants to be sued, even big ones by individual kernel developers) is because so few kernel developers have actually sued anyone for writing proprietary drivers. So here's my message to VJ, from a legal standpoint: don't worry about it. No-one who authored code you're linking your code against is likely to go on a suing spree anytime soon, they're too busy coding. You've already got my message from a moral point of view (and I'm still terribly confused about your reply). Trent - 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: move struct sysfs_dirent to private header
Hi Greg,
This is a resubmission of a patch that fell through the
cracks long ago. I've posted it a couple of times, and don't recall
anyone objecting to it.
struct sysfs_dirent is private to the fs/sysfs/ subtree. It is
not even referenced as an opaque structure outside of that subtree.
The following patch moves the declaration from
include/linux/sysfs.h to fs/sysfs/sysfs.h, making it clearer
that nothing else in the kernel dereferences it.
I have been running this patch for years. Please integrate
and forward upstream if there are no objections.
Note that while this patch was generated by stgit, it
was not generated from a tree pulled from kernel.org, so perhaps
a git command that thinks that this patch was generated from a
common ancestor might get confused (I'm not sure). You may want
to integrate it by running patch and checking in the change.
The patch is against 2.6.20-git11.
Adam Richter
Move struct sysfs_dirent from incude/linux/sysfs.h to fs/sysfs/sysfs.h
From:
---
src/fs/sysfs/sysfs.h | 11 +++
src/include/linux/sysfs.h | 12
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/src/fs/sysfs/sysfs.h b/src/fs/sysfs/sysfs.h
index d976b00..a77c57e 100644
--- a/src/fs/sysfs/sysfs.h
+++ b/src/fs/sysfs/sysfs.h
@@ -1,3 +1,14 @@
+struct sysfs_dirent {
+ atomic_ts_count;
+ struct list_heads_sibling;
+ struct list_heads_children;
+ void* s_element;
+ int s_type;
+ umode_t s_mode;
+ struct dentry * s_dentry;
+ struct iattr* s_iattr;
+ atomic_ts_event;
+};
extern struct vfsmount * sysfs_mount;
extern struct kmem_cache *sysfs_dir_cachep;
diff --git a/src/include/linux/sysfs.h b/src/include/linux/sysfs.h
index 192de3a..567cdca 100644
--- a/src/include/linux/sysfs.h
+++ b/src/include/linux/sysfs.h
@@ -68,18 +68,6 @@ struct sysfs_ops {
ssize_t (*store)(struct kobject *,struct attribute *,const char *,
size_t);
};
-struct sysfs_dirent {
- atomic_ts_count;
- struct list_heads_sibling;
- struct list_heads_children;
- void* s_element;
- int s_type;
- umode_t s_mode;
- struct dentry * s_dentry;
- struct iattr* s_iattr;
- atomic_ts_event;
-};
-
#define SYSFS_ROOT 0x0001
#define SYSFS_DIR 0x0002
#define SYSFS_KOBJ_ATTR0x0004
Re: bloc_til_ready in tty driver
Thanx for your respond, I did not implement this function in my tty driver. Does it help to work my driver with cat Linux operation? (e.g. cat ttyS10) Mockern napsal(a): What for is bloc_til_ready function in tty drivers? Most drivers waits for hardware to detect carrier and for closed callout. regards, -- Сегодня удачный день, чтобы завести почту на Яндексе http://mail.yandex.ru - 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/1] unify queue_delayed_work and queue_delayed_work_on fix
On 02/16, Jiri Slaby wrote: unify queue_delayed_work and queue_delayed_work_on fix Since cwq-wq is unset for other than singlethread_cpu when singlethread workqueue was created, an oops occurs during bootup. And I thought I tested this... Fix it by setting correct private value for workqueue. Thanks!!! Signed-off-by: Jiri Slaby [EMAIL PROTECTED] --- commit 7bc281be5811f9b1dd01c25eaf492f4765737fd0 tree 7795008066bb89e7489384cde95e63260602d5af parent 61c2024a2dd044e32747542cfbf4b22251df3bc2 author Jiri Slaby [EMAIL PROTECTED] Fri, 16 Feb 2007 00:49:15 +0100 committer Jiri Slaby [EMAIL PROTECTED] Fri, 16 Feb 2007 00:49:15 +0100 kernel/workqueue.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index f2089bf..af5e597 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -210,7 +210,8 @@ int queue_delayed_work_on(int cpu, struct workqueue_struct *wq, /* This stores cwq for the moment, for the timer_fn */ set_wq_data(work, - per_cpu_ptr(wq-cpu_wq, raw_smp_processor_id())); + per_cpu_ptr(wq-cpu_wq, wq-singlethread ? + singlethread_cpu : raw_smp_processor_id())); timer-expires = jiffies + delay; timer-data = (unsigned long)dwork; timer-function = delayed_work_timer_fn; - 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: cat, cp operations for tty driver (like for char one)
Thanx for your respond. Does it mean I have to change nothing in my tty driver (based on serial_core.c) to use: cat and cp? No nonstandard special functions to implement? On Thu, 15 Feb 2007, Mockern wrote: I have a question about linux tty driver how to support cp, cat operations in tty driver (like tiny_tty)? (e.g. echo hello tty /dev/ttyS3, cat ttyS10 etc) There a lot of examples with char drivers, but I could not find it for tty Linux driver. It works out of the box. Just keep hardware flow-control turned off if there are no receivers connected to the output port. Also, you need to set up the port's baud-rate and (usually) to make it transparent to control characters (man tc-get/set-attr). Cheers, Dick Johnson Penguin : Linux version 2.6.16.24 on an i686 machine (5592.61 BogoMips). New book: http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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/
