Re: Full preemption issues
On Fri, 27 Oct 2000, George Anzinger wrote: > > First, as you know, we have added code to the spinlock macros to count > up and down a preemption lock counter. We would like to not do this if > the macro also turns off local interrupts. The issue here is that in > some places in the code, spin_lock_irq() or spin_lock_irqsave() is > called but spin_unlock_irq() or spin_lock_irqrestore() is not. This, of > course, confuses the preemption count. Attached is a patch that > addresses this issue. At this time we are not asking you to apply this > patch, but to indicate if we are moving in an acceptable direction. Looks entirely sane to me. > The second issue resolves around the naming conventions used in the > kernel. We want to extend this work to include the SMP kernel, but to > do this we need to have several levels of names for the spinlock > macros. We note that the kernel uses "_" and "__" prefixes in some > macros, but can not, by inspection, figure out when to uses these > prefixes. Could you explain this convention or is this wisdom written > somewhere? The "wisdom" is not written down anywhere, and is more a convention than anything else. The convention is that a prepended "__" means that "this is an internal routine, and you can use it, but you should damn well know what you're doing if you do". For example, the most common use is for routines that need external locking - the version that does its own locking and is thus "safe" to use in normal circumstances has the regular name, and the version of the routine that does no locking and depends on the caller to lock for it has the "__" version. Your proto code does not break this convention in any way.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Full preemption issues
On Fri, 27 Oct 2000, George Anzinger wrote: First, as you know, we have added code to the spinlock macros to count up and down a preemption lock counter. We would like to not do this if the macro also turns off local interrupts. The issue here is that in some places in the code, spin_lock_irq() or spin_lock_irqsave() is called but spin_unlock_irq() or spin_lock_irqrestore() is not. This, of course, confuses the preemption count. Attached is a patch that addresses this issue. At this time we are not asking you to apply this patch, but to indicate if we are moving in an acceptable direction. Looks entirely sane to me. The second issue resolves around the naming conventions used in the kernel. We want to extend this work to include the SMP kernel, but to do this we need to have several levels of names for the spinlock macros. We note that the kernel uses "_" and "__" prefixes in some macros, but can not, by inspection, figure out when to uses these prefixes. Could you explain this convention or is this wisdom written somewhere? The "wisdom" is not written down anywhere, and is more a convention than anything else. The convention is that a prepended "__" means that "this is an internal routine, and you can use it, but you should damn well know what you're doing if you do". For example, the most common use is for routines that need external locking - the version that does its own locking and is thus "safe" to use in normal circumstances has the regular name, and the version of the routine that does no locking and depends on the caller to lock for it has the "__" version. Your proto code does not break this convention in any way.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
