* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
@ 2005-01-17 23:22 ` Michael Veeck
2005-01-17 23:47 ` Randy.Dunlap
` (49 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Michael Veeck @ 2005-01-17 23:22 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 18032 bytes --]
Hi!
I just wanted to check on how the general policy on maintaining patches
is since I have done the min/max stuff and some still remain in the
kernel. Mostly because the maintainers dont seem to incoporate them
(isdn-eicorn for example was send nearly one year ago).
So shall the remaining min/max stuff be left alone or should at least
something be written into Documenteation/*.txt, maybe as a hint for
future generations?
As another easy task which might be useful for a newbie is to find other
dupicate definitions. When looking myself for MinMax macros, I also
stumbled over multiple ARRAY_SIZE().
And then there is still the question if BIT(x) should be made general
which also is defined multiple times.
Best regards
MVeeck
Domen Puncer schrieb:
> Hi.
>
> Removed some finished, invalid, duplicate entries.
> Replaced inline explanation with summary and URL to original post.
> Comments, objections to any change?
>
> Second stage, that i'm doing now is to put stuff into sections (like it
> is at the beginning of file).
> I'm also thinking about ordering from easiest to hardest.
> Ideas, comments?
>
>
>
> TODO-1.26 | 320 +++-----------------------------------------------------------
> 1 files changed, 18 insertions(+), 302 deletions(-)
>
> --- TODO-1.25 2005-01-17 21:18:24.000000000 +0100
> +++ TODO-1.26 2005-01-17 23:45:15.000000000 +0100
> @@ -44,7 +44,6 @@
> Remove unneeded historic code / New API conversions.
> - checking for NULL on probe routines for net drivers
> - convert drivers to new PCI API
> -- get rid of save_flags_cli, use local_irq_save instead
> - get rid of check_region, use just request_region checking its return (2.2
> request_region returned void) and now the driver init sequence is not to be
> serialized anymore, so races are possible (look at cardbus/pcihotplug code)
> @@ -57,8 +56,6 @@
> Many of these fixed already at:
> http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-11/0150.html
> FIXME: Dead URL!
> -- Net drivers should call SET_MODULE_OWNER instead of MOD_{INC,DEC}_USE_COUNT
> -- There are still kernel threads which don't use up_and_exit() for dying.
> - Purely cosmetic, but far nicer to read..
> - for (list = ymf_devs.next; list != &ymf_devs; list = list->next) {
> + list_for_each(list, &ymf_devs) {
> @@ -66,12 +63,6 @@
> instead of reading directly.
> - dev->driver_data = pcigame;
> + pci_set_drvdata(dev, pcigame);
> -- Take end_request() definition out of blk.h and move it into the drivers that need it.
> - IOW, ones that contain calls of end_request() and don't have LOCAL_END_REQUEST defined.
> - once that's done, kill LOCAL_END_REQUEST... (suggested by Al Viro)
> -
> -SUSPECTS:
> -- de4x5.c doesn't pci_enable_device()
>
> -----------------------------------------------------------------------------
> Copying to/from userspace issues.
> @@ -84,10 +75,7 @@
> - use "return copy_*_user(...) ? -EFAULT : ok_value;"
>
> SUSPECTS:
> -- look at drivers/char/generic_serial.c
> - look at drivers/char/n_tty.c
> -- check drivers/char/dz.c wrt return copy*user(...);
> - has to be ... ? -EFAULT : 0;
>
> -----------------------------------------------------------------------------
> - get rid of isa_read/write[bwl], use ioremap instead
> @@ -166,81 +154,12 @@
> -----------------------------------------------------------------------------
> From: David Woodhouse <dwmw2 at infradead dot org>
>
> -- Anything which uses sleep_on() has a 90% chance of being broken. Fix
> +- Anything which uses sleep_on*() has a 90% chance of being broken. Fix
> them all, because we want to remove sleep_on() and friends in 2.5.
>
> -Explanation by Andi Kleen <ak at suse dot de>
> lkml thread at:
> http://boudicca.tux.org/hypermail/linux-kernel/2001week05/0305.html
> -
> -> don't even know WHY it's bad. Not only that, but what am I supposed to use
> -> instead?
> -
> -You can miss wakeups. The standard pattern is:
> -
> - get locks
> -
> - add_wait_queue(&waitqueue, &wait);
> - for (;;) {
> - if (condition you're waiting for is true)
> - break;
> - unlock any non sleeping locks you need for condition
> - __set_task_state(current, TASK_UNINTERRUPTIBLE);
> - schedule();
> - __set_task_state(current, TASK_RUNNING);
> - reaquire locks
> - }
> - remove_wait_queue(&waitqueue, &wait);
> -
> -When you want to handle signals you can check for them before or after the
> -condition check. Also use TASK_INTERRUPTIBLE in this case.
> -
> -When you need a timeout use schedule_timeout().
> -
> -For some cases you can also use the wait_event_* macros which encapsulate
> -that for you, assuming condition can be tested/used lockless.
> -
> -An alternative is to use a semaphore, although that behaves a bit differently
> -under load.
> -
> -From: David Woodhouse <dwmw2 at infradead dot org>
> -
> -> Ok, so how should this code have been written?
> -
> -DECLARE_WAIT_QUEUE(wait, current);
> -
> -while(1) {
> - do_something_important()
> -
> - set_current_state(TASK_INTERRUPTIBLE);
> - add_wait_queue(&q, &wait);
> -
> - /* Now if something arrives, we'll be 'woken' immediately -
> - - that is; our state will be set to TASK_RUNNING */
> -
> - if (!stuff_to_do()) {
> - /* If the 'stuff' arrives here, we get woken anyway,
> - so the schedule() returns immediately. You
> - can use schedule_timeout() here if you need
> - a timeout, obviously */
> - schedule();
> - }
> -
> - set_current_state(TASK_RUNNING);
> - remove_wait_queue(&q, &wait);
> -
> - if (signal_pending(current)) {
> - /* You've been signalled. Deal with it. If you don't
> - want signals to wake you, use TASK_UNINTERRUPTIBLE
> - above instead of TASK_INTERRUPTIBLE. Be aware
> - that you'll add one to the load average all the
> - time your task is sleeping then. */
> - return -EINTR;
> - }
> -}
> -
> -Alternatively, you could up() a semaphore for each task that's do be done,
> -and down() it again each time you remove one from the queue.
> +Be sure to read replies too.
>
> -----------------------------------------------------------------------------
> From: Andrew Morton <andrewm at uow dot edu dot au>
> @@ -431,7 +350,7 @@
> interfaces:
>
> - call SET_MODULE_OWNER or use .owner = THIS_MODULE instead of using
> - MOD_{INC,DEC}_USE_COUNT
> + MOD_{INC,DEC}_USE_COUNT (only a few remain)
>
> - convert cli/sti/save_flags/save_flags_cli/restore_flags usage to
> accepted locking primitives;
> @@ -439,16 +358,6 @@
> for details, belows patch is an example:
> http://linux.bkbits.net:8080/linux-2.6/cset@419b78fcaLKtZt39OF_dslTbk-b3KQ?nav=index.html|ChangeSet@-8w
>
> -- These drivers need DMA usage attention:
> -./drivers/net/defxx.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/net/rcpci45.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/scsiiom.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/ini9100u.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/AM53C974.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/gdth.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/dpt_i2o.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/pci2220i.c:#error Convert me to understand page+offset based scatterlists
> -
> ------------------------------------------------------------------------
> From Linus:
>
> @@ -458,10 +367,6 @@
> http://kernelnewbies.org/scripts/ .
>
> ------------------------------------------------------------------------
> -Fix source code formatting, especially in unmaintained source files.
> -For example, arch/i386/math-emu/fpu_entry.c .
> -
> -------------------------------------------------------------------------
> For source files that don't have any license information in them,
> determine if they should be GPL or GPL/BSD etc. and add license information
> to them.
> @@ -476,90 +381,22 @@
> may be false alarms, not all are bugs.
>
> ------------------------------------------------------------------------
> -From Domen Puncer:
> - pr_debug() from kernel.h could replace a lot of DPRINTK and similar macros.
> - same for pr_info()
> -
> -------------------------------------------------------------------------
> -From Domen Puncer:
> - min/max macros from kernel.h are safe, a lot of handcrafted MIN/MAX are not.
> -
> -------------------------------------------------------------------------
> -From Domen Puncer:
> - remove string concatenation with __FUNCTION__ (get rid of
> -warnings, and get ready for __func__):
> --printk(KERN_INFO "blabla " __FUNCTION__ "\n");
> -+printk(KERN_INFO "blabla %s\n", __FUNCTION__);
> -
> -However, do not convert _FUNCTION_ to _func_ because older
> -gcc versions do not support _func_.
> + warnings, and get ready for __func__):
> + -printk(KERN_INFO "blabla " __FUNCTION__ "\n");
> + +printk(KERN_INFO "blabla %s\n", __FUNCTION__);
>
> ------------------------------------------------------------------------
> From: Matthew Wilcox
> Subject: Calling yield() Considered Harmful
>
> -In 2.6, the semantics of calling yield() changed from "sleep for a
> -bit" to "I really don't want to run for a while". This matches POSIX
> -better, but there's a lot of drivers still using yield() when they mean
> -cond_resched(), schedule() or even schedule_timeout().
> -
> -Here's a list:
> -
> -$ find drivers/ -type f |xargs grep 'yield[^a-z]*('
> -drivers/cdrom/cdu31a.c: yield();
> -drivers/cdrom/sonycd535.c: yield();
> -drivers/macintosh/adb.c: yield();
> -drivers/message/i2o/i2o_core.c: yield();
> -drivers/message/i2o/i2o_core.c: yield();
> -drivers/mtd/chips/cfi_cmdset_0002.c: yield();
> -drivers/mtd/nand/nand.c: yield ();
> -drivers/net/depca.c: yield();
> -drivers/net/sb1000.c: yield();
> -drivers/net/sb1000.c: yield();
> -drivers/net/sis900.c: yield();
> -drivers/net/sungem.c: yield();
> -drivers/scsi/NCR5380.c: yield();
> -drivers/scsi/ibmmca.c: yield();
> -drivers/scsi/megaraid.c: udelay(100); yield();
> -drivers/usb/core/message.c: yield ();
> -
> -As always, this isn't a search-and-replace type of job. Let's take
> -the first one as an example:
> -
> -static inline void sony_sleep(void)
> -{
> - unsigned long flags;
> -
> - if (cdu31a_irq <= 0) {
> - yield();
> - } else { /* Interrupt driven */
> - save_flags(flags);
> - cli();
> - enable_interrupts();
> - interruptible_sleep_on(&cdu31a_irq_wait);
> - restore_flags(flags);
> - }
> -}
> -
> -If you look at how sony_sleep() is typically used, what you really want to
> -do is schedule_timeout(1). But someone needs to look at all these cases..
> -do I hear a volunteer?
> -
> -Addendum: Typically just before calling schedule_timeout(),
> -a function needs to do something like:
> - set_current_state(TASK_INTERRUPTIBLE);
> -
> -based on kernel/timer.c::schedule_timeout(), which says:
> -The routine [schedule_timeout] will return immediately unless
> -the current task state has been set (see set_current_state()).
> -
> -Addendum From: Greg KH
> -
> --> most of the longer delays in the kernel can be converted to use
> - msleep() as it will work properly. drivers should it instead of
> - creating their own (incorrect) function.
> - (example: sony_sleep(void) in drivers/cdrom/sonycd535.c)
> -
> +[T: http://marc.theaimsgroup.com/?t=106554796200005]
> +Don't forget to set_current_state(TASK_{,UN}INTERRUPTIBLE); before
> +schedule*().
> +Consider using msleep();.
>
> ------------------------------------------------------------------------
> From: Eugene Teo
> @@ -582,66 +419,11 @@
>
>
> ------------------------------------------------------------------------
> -From: Keith Owens
> -To: Andrew Morton
> -Subject: Re: Latest reference_init.pl script
> -
> -On Mon, 31 May 2004 23:52:14 -0700,
> -Andrew Morton wrote:
> ->
> ->gad, reference_init generates so much stuff I wonder if it's worth using.
> ->Are all these for real?
> -
> -Apart from altinstructions, yes. Mainly because people have not been
> -checking them.
> -
> ->perl scripts/reference_init.pl
> ->Finding objects, 1411 objects, ignoring 122 module(s)
> ->Finding conglomerates, ignoring 137 conglomerate(s)
> ->Scanning objects
> ->Error: ./arch/i386/kernel/apic.o .data refers to 0000009c R_386_32 .init.text
> +From: Keith Owens, Andrew Morton
>
> -arch/i386/kernel/apic.c
> -void (*wait_timer_tick)(void) = wait_8254_wraparound;
> -wait_8254_wraparound is __init. wait_timer_tick should be __initdata,
> -which flows onto several other functions.
> -
> ->Error: ./arch/i386/kernel/cpu/mtrr/centaur.o .data refers to 00000008 R_386_32 .init.text
> -
> -That is real, centaur_mtrr_ops.init = centaur_mcr_init. Like a lot of
> -this initialization code, we get away with the dangling reference
> -because the code is only executed at boot.
> -
> ->Error: ./arch/i386/kernel/cpu/mtrr/centaur.o .eh_frame refers to 000000dc R_386_32 .init.text
> -
> -I don't see any .eh_frame references in 2.6.7-rc2 using gcc version
> -3.3.3 20040412 (Red Hat Linux 3.3.3-7). Where are they coming from?
> -
> ->Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .data refers to 00000028 R_386_32 .init.text
> -
> -Same as centaur.
> -
> ->Error: ./arch/i386/kernel/cpu/mtrr/generic.o .text refers to 0000038f R_386_32 .init.data
> -
> -arch/i386/kernel/cpu/mtrr/generic.c
> -generic_set_all() uses __intdata smp_changes_mask.
> -
> ->Error: ./arch/i386/kernel/smpboot.o .altinstructions refers to 00000000 R_386_32 .init.text
> -
> -altinstructions is a false positive, tweak reference_init.pl
> -
> ---- reference_init.pl.orig 2004-06-01 20:30:27.000000000 +1000
> -+++ reference_init.pl 2004-06-01 20:31:01.000000000 +1000
> -@@ -93,6 +93,7 @@
> - $from !~ /\.stab$/ &&
> - $from !~ /\.rodata$/ &&
> - $from !~ /\.text\.lock$/ &&
> -+ $from !~ /\.altinstructions$/ &&
> - $from !~ /\.debug_/)) {
> - printf("Error: %s %s refers to %s\n", $object, $from, $line);
> - }
> -
> -The rest of the warnings look real, apart from the strange eh_frame.
> +Code in wrong sections:
> +[http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=108640220401558]
> +Run `make buildcheck` to find offending code
>
> ----------------------------------------------------------------------
> From: Rusty Russell
> @@ -667,81 +449,15 @@
> From: Matt Domsch
> Sat Jul 24 10:51:04 PDT 2004
>
> -Request for Patches
> -
> -The 2.6.x kernel includes a MODULE_VERSION() parameter for providing
> -one convenient way for all modules to state what *their* version is
> -(as opposed to the version of the larger kernel they're included in).
> -
> -I've started submitting patches to the subsystem maintainers to add
> -MODULE_VERSION() entries for drivers that I particularly care about,
> -and would appreciate assistance handling the others.
> -
> -For modules which display their version as a string somewhere via
> -printk, the preferred mechanism is:
> -
> -#define DRV_VERSION "1.0.0"
> -MODULE_VERSION(DRV_VERSION);
> -
> -One aspect of MODULE_VERSION I haven't tackled is re-formatting
> -existing versions into the preferred method as found in include/linux/module.h:
> -
> -/* Version of form [<epoch>:]<version>[-<extra-version>].
> - Or for CVS/RCS ID version, everything but the number is stripped.
> - <epoch>: A (small) unsigned integer which allows you to start
> - versions
> - anew. If not mentioned, it's zero. eg. "2:1.0" is after
> - "1:2.0".
> - <version>: The <version> may contain only alphanumerics and the
> - character `.'. Ordered by numeric sort for numeric parts,
> - ascii sort for ascii parts (as per RPM or DEB algorithm).
> - <extraversion>: Like <version>, but inserted for local
> - customizations, eg "rh3" or "rusty1".
> -*/
> -
> -I leave such reformatting up to each driver author and/or patch
> -submitter.
> -
> -Thanks,
> -Matt
> +Add MODULE_VERSION() to modules.
> +[http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=109068085714776]
>
> ----------------------------------------------------------------------
> From: Andi Kleen
> Date: Sun, 19 Dec 2004 20:09:03 +0100
>
> -Here's a proposed janitor project if anybody is interested:
> -
> -The current gcc 4.0 snapshots include some more warnings in -Wall
> -and changed some existing ones which makes a kernel compilation quite noisy.
> -
> -The project would be to fix all these warnings.
> -
> -Short howto:
> -
> -Get
> -ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20041219/gcc-core-4.0-20041219.tar.bz2
> -
> -Untar it and compile with
> -
> -mkdir obj
> -../gcc-*/configure --disable-checking --enable-languages=c --prefix=/usr/local/gcc4
> -make bootstrap
> -<as root>
> -make install
> -
> -
> -Then compile an uptodate 2.6 kernel with:
> -
> -make allmodconfig
> -make CC=/usr/local/gcc4/bin/gcc 2>&1 | tee LOG
> -grep warning LOG
> -
> -You'll see lots of warnings in LOG. Fix them all and submit patches
> -through the usual janitor channels.
> -
> --Andi
> -
> -[thread at http://marc.theaimsgroup.com/?t=110348353800003&r=1&w=2]
> +Fix gcc 4 warnings.
> +[http://marc.theaimsgroup.com/?t=110348353800003]
>
> ----------------------------------------------------------------------
> From: Felipe W Damasio
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kernel-janitors mailing list
> Kernel-janitors@lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/kernel-janitors
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
2005-01-17 23:22 ` Michael Veeck
@ 2005-01-17 23:47 ` Randy.Dunlap
2005-01-18 0:02 ` Domen Puncer
` (48 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Randy.Dunlap @ 2005-01-17 23:47 UTC (permalink / raw)
To: kernel-janitors
Domen Puncer wrote:
> On 18/01/05 03:03 +0200, Alexey Dobriyan wrote:
>
>>On Tuesday 18 January 2005 01:11, Domen Puncer wrote:
>>
>>
>>>Removed some finished, invalid, duplicate entries.
>>>Replaced inline explanation with summary and URL to original post.
>>>Comments, objections to any change?
>>
>>...
>>
>>
>>>+Fix gcc 4 warnings.
>>>+[http://marc.theaimsgroup.com/?t\x110348353800003]
>>
>>CONFIG_DEBUG_INFO=n wasn't mentioned at this thread.
>
>
> No it wasn't.
> It's used to make compiles faster, I assume?
> I'll add a note.
Yes, and use less disk space.... (lots less)
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
2005-01-17 23:22 ` Michael Veeck
2005-01-17 23:47 ` Randy.Dunlap
@ 2005-01-18 0:02 ` Domen Puncer
2005-01-18 0:06 ` Alexey Dobriyan
` (47 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Domen Puncer @ 2005-01-18 0:02 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 17922 bytes --]
On 18/01/05 00:11 +0100, Domen Puncer wrote:
> Hi.
>
> Removed some finished, invalid, duplicate entries.
> Replaced inline explanation with summary and URL to original post.
> Comments, objections to any change?
Some comments from me:
>
>
> TODO-1.26 | 320 +++-----------------------------------------------------------
> 1 files changed, 18 insertions(+), 302 deletions(-)
>
> --- TODO-1.25 2005-01-17 21:18:24.000000000 +0100
> +++ TODO-1.26 2005-01-17 23:45:15.000000000 +0100
> @@ -44,7 +44,6 @@
> Remove unneeded historic code / New API conversions.
> - checking for NULL on probe routines for net drivers
> - convert drivers to new PCI API
> -- get rid of save_flags_cli, use local_irq_save instead
Duplicate.
> - get rid of check_region, use just request_region checking its return (2.2
> request_region returned void) and now the driver init sequence is not to be
> serialized anymore, so races are possible (look at cardbus/pcihotplug code)
> @@ -57,8 +56,6 @@
> Many of these fixed already at:
> http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-11/0150.html
> FIXME: Dead URL!
> -- Net drivers should call SET_MODULE_OWNER instead of MOD_{INC,DEC}_USE_COUNT
Done.
> -- There are still kernel threads which don't use up_and_exit() for dying.
up_and_exit() doesn't exist anymore.
> - Purely cosmetic, but far nicer to read..
> - for (list = ymf_devs.next; list != &ymf_devs; list = list->next) {
> + list_for_each(list, &ymf_devs) {
> @@ -66,12 +63,6 @@
> instead of reading directly.
> - dev->driver_data = pcigame;
> + pci_set_drvdata(dev, pcigame);
> -- Take end_request() definition out of blk.h and move it into the drivers that need it.
> - IOW, ones that contain calls of end_request() and don't have LOCAL_END_REQUEST defined.
> - once that's done, kill LOCAL_END_REQUEST... (suggested by Al Viro)
Seems done.
There's no blk.h, only LOCAL_END_REQUEST is an empty define from floppy.c
> -
> -SUSPECTS:
> -- de4x5.c doesn't pci_enable_device()
Does now:
domen@nd47:~/kernel/a$ grep pci_enable_device drivers/net/tulip/de4x5.c
if ((error = pci_enable_device (pdev)))
>
> -----------------------------------------------------------------------------
> Copying to/from userspace issues.
> @@ -84,10 +75,7 @@
> - use "return copy_*_user(...) ? -EFAULT : ok_value;"
>
> SUSPECTS:
> -- look at drivers/char/generic_serial.c
It checks now.
domen@nd47:~/kernel/a$ egrep "copy_(from|to)_user" drivers/char/generic_serial.c
fault) in copy_from_user */
if (copy_from_user(&sio, sp, sizeof(struct serial_struct)))
if (copy_to_user(sp, &sio, sizeof(struct serial_struct)))
> - look at drivers/char/n_tty.c
> -- check drivers/char/dz.c wrt return copy*user(...);
> - has to be ... ? -EFAULT : 0;
ENOFILE,
the one from drivers/serial/ doesn't have copy_to/from_user
>
> -----------------------------------------------------------------------------
> - get rid of isa_read/write[bwl], use ioremap instead
> @@ -166,81 +154,12 @@
> -----------------------------------------------------------------------------
> From: David Woodhouse <dwmw2 at infradead dot org>
>
> -- Anything which uses sleep_on() has a 90% chance of being broken. Fix
> +- Anything which uses sleep_on*() has a 90% chance of being broken. Fix
Uh :-)
> them all, because we want to remove sleep_on() and friends in 2.5.
>
> -Explanation by Andi Kleen <ak at suse dot de>
> lkml thread at:
> http://boudicca.tux.org/hypermail/linux-kernel/2001week05/0305.html
Don't see point in mail contents copied in here.
> -
> -> don't even know WHY it's bad. Not only that, but what am I supposed to use
> -> instead?
> -
> -You can miss wakeups. The standard pattern is:
> -
> - get locks
> -
> - add_wait_queue(&waitqueue, &wait);
> - for (;;) {
> - if (condition you're waiting for is true)
> - break;
> - unlock any non sleeping locks you need for condition
> - __set_task_state(current, TASK_UNINTERRUPTIBLE);
> - schedule();
> - __set_task_state(current, TASK_RUNNING);
> - reaquire locks
> - }
> - remove_wait_queue(&waitqueue, &wait);
> -
> -When you want to handle signals you can check for them before or after the
> -condition check. Also use TASK_INTERRUPTIBLE in this case.
> -
> -When you need a timeout use schedule_timeout().
> -
> -For some cases you can also use the wait_event_* macros which encapsulate
> -that for you, assuming condition can be tested/used lockless.
> -
> -An alternative is to use a semaphore, although that behaves a bit differently
> -under load.
> -
> -From: David Woodhouse <dwmw2 at infradead dot org>
> -
> -> Ok, so how should this code have been written?
> -
> -DECLARE_WAIT_QUEUE(wait, current);
> -
> -while(1) {
> - do_something_important()
> -
> - set_current_state(TASK_INTERRUPTIBLE);
> - add_wait_queue(&q, &wait);
> -
> - /* Now if something arrives, we'll be 'woken' immediately -
> - - that is; our state will be set to TASK_RUNNING */
> -
> - if (!stuff_to_do()) {
> - /* If the 'stuff' arrives here, we get woken anyway,
> - so the schedule() returns immediately. You
> - can use schedule_timeout() here if you need
> - a timeout, obviously */
> - schedule();
> - }
> -
> - set_current_state(TASK_RUNNING);
> - remove_wait_queue(&q, &wait);
> -
> - if (signal_pending(current)) {
> - /* You've been signalled. Deal with it. If you don't
> - want signals to wake you, use TASK_UNINTERRUPTIBLE
> - above instead of TASK_INTERRUPTIBLE. Be aware
> - that you'll add one to the load average all the
> - time your task is sleeping then. */
> - return -EINTR;
> - }
> -}
> -
> -Alternatively, you could up() a semaphore for each task that's do be done,
> -and down() it again each time you remove one from the queue.
> +Be sure to read replies too.
>
> -----------------------------------------------------------------------------
> From: Andrew Morton <andrewm at uow dot edu dot au>
> @@ -431,7 +350,7 @@
> interfaces:
>
> - call SET_MODULE_OWNER or use .owner = THIS_MODULE instead of using
> - MOD_{INC,DEC}_USE_COUNT
> + MOD_{INC,DEC}_USE_COUNT (only a few remain)
yay!
>
> - convert cli/sti/save_flags/save_flags_cli/restore_flags usage to
> accepted locking primitives;
> @@ -439,16 +358,6 @@
> for details, belows patch is an example:
> http://linux.bkbits.net:8080/linux-2.6/cset@419b78fcaLKtZt39OF_dslTbk-b3KQ?nav=index.html|ChangeSet@-8w
>
> -- These drivers need DMA usage attention:
> -./drivers/net/defxx.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/net/rcpci45.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/scsiiom.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/ini9100u.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/AM53C974.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/gdth.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/dpt_i2o.c:#error Please convert me to Documentation/DMA-mapping.txt
> -./drivers/scsi/pci2220i.c:#error Convert me to understand page+offset based scatterlists
> -
Seems done.
> ------------------------------------------------------------------------
> From Linus:
>
> @@ -458,10 +367,6 @@
> http://kernelnewbies.org/scripts/ .
>
> ------------------------------------------------------------------------
> -Fix source code formatting, especially in unmaintained source files.
> -For example, arch/i386/math-emu/fpu_entry.c .
> -
I remember a post from Linus about dropping formatting patches.
Ok, for unmaintained files clashing with other patches might not
be the problem. But what's the point of fixing files that noone looks
at?
> -------------------------------------------------------------------------
> For source files that don't have any license information in them,
> determine if they should be GPL or GPL/BSD etc. and add license information
> to them.
> @@ -476,90 +381,22 @@
> may be false alarms, not all are bugs.
>
> ------------------------------------------------------------------------
> -From Domen Puncer:
> - pr_debug() from kernel.h could replace a lot of DPRINTK and similar macros.
> - same for pr_info()
> -
> -------------------------------------------------------------------------
> -From Domen Puncer:
> - min/max macros from kernel.h are safe, a lot of handcrafted MIN/MAX are not.
> -
> -------------------------------------------------------------------------
> -From Domen Puncer:
> - remove string concatenation with __FUNCTION__ (get rid of
> -warnings, and get ready for __func__):
> --printk(KERN_INFO "blabla " __FUNCTION__ "\n");
> -+printk(KERN_INFO "blabla %s\n", __FUNCTION__);
> -
> -However, do not convert _FUNCTION_ to _func_ because older
> -gcc versions do not support _func_.
> + warnings, and get ready for __func__):
> + -printk(KERN_INFO "blabla " __FUNCTION__ "\n");
> + +printk(KERN_INFO "blabla %s\n", __FUNCTION__);
compress :-)
>
> ------------------------------------------------------------------------
> From: Matthew Wilcox
> Subject: Calling yield() Considered Harmful
>
We got url to this.
> -In 2.6, the semantics of calling yield() changed from "sleep for a
> -bit" to "I really don't want to run for a while". This matches POSIX
> -better, but there's a lot of drivers still using yield() when they mean
> -cond_resched(), schedule() or even schedule_timeout().
> -
> -Here's a list:
> -
> -$ find drivers/ -type f |xargs grep 'yield[^a-z]*('
> -drivers/cdrom/cdu31a.c: yield();
> -drivers/cdrom/sonycd535.c: yield();
> -drivers/macintosh/adb.c: yield();
> -drivers/message/i2o/i2o_core.c: yield();
> -drivers/message/i2o/i2o_core.c: yield();
> -drivers/mtd/chips/cfi_cmdset_0002.c: yield();
> -drivers/mtd/nand/nand.c: yield ();
> -drivers/net/depca.c: yield();
> -drivers/net/sb1000.c: yield();
> -drivers/net/sb1000.c: yield();
> -drivers/net/sis900.c: yield();
> -drivers/net/sungem.c: yield();
> -drivers/scsi/NCR5380.c: yield();
> -drivers/scsi/ibmmca.c: yield();
> -drivers/scsi/megaraid.c: udelay(100); yield();
> -drivers/usb/core/message.c: yield ();
> -
> -As always, this isn't a search-and-replace type of job. Let's take
> -the first one as an example:
> -
> -static inline void sony_sleep(void)
> -{
> - unsigned long flags;
> -
> - if (cdu31a_irq <= 0) {
> - yield();
> - } else { /* Interrupt driven */
> - save_flags(flags);
> - cli();
> - enable_interrupts();
> - interruptible_sleep_on(&cdu31a_irq_wait);
> - restore_flags(flags);
> - }
> -}
> -
> -If you look at how sony_sleep() is typically used, what you really want to
> -do is schedule_timeout(1). But someone needs to look at all these cases..
> -do I hear a volunteer?
> -
> -Addendum: Typically just before calling schedule_timeout(),
> -a function needs to do something like:
> - set_current_state(TASK_INTERRUPTIBLE);
> -
> -based on kernel/timer.c::schedule_timeout(), which says:
> -The routine [schedule_timeout] will return immediately unless
> -the current task state has been set (see set_current_state()).
> -
> -Addendum From: Greg KH
> -
> --> most of the longer delays in the kernel can be converted to use
> - msleep() as it will work properly. drivers should it instead of
> - creating their own (incorrect) function.
> - (example: sony_sleep(void) in drivers/cdrom/sonycd535.c)
> -
> +[T: http://marc.theaimsgroup.com/?t=106554796200005]
> +Don't forget to set_current_state(TASK_{,UN}INTERRUPTIBLE); before
> +schedule*().
> +Consider using msleep();.
>
> ------------------------------------------------------------------------
> From: Eugene Teo
> @@ -582,66 +419,11 @@
>
>
> ------------------------------------------------------------------------
Copy of a mail:
> -From: Keith Owens
> -To: Andrew Morton
> -Subject: Re: Latest reference_init.pl script
> -
> -On Mon, 31 May 2004 23:52:14 -0700,
> -Andrew Morton wrote:
> ->
> ->gad, reference_init generates so much stuff I wonder if it's worth using.
> ->Are all these for real?
> -
> -Apart from altinstructions, yes. Mainly because people have not been
> -checking them.
> -
> ->perl scripts/reference_init.pl
> ->Finding objects, 1411 objects, ignoring 122 module(s)
> ->Finding conglomerates, ignoring 137 conglomerate(s)
> ->Scanning objects
> ->Error: ./arch/i386/kernel/apic.o .data refers to 0000009c R_386_32 .init.text
> +From: Keith Owens, Andrew Morton
>
> -arch/i386/kernel/apic.c
> -void (*wait_timer_tick)(void) = wait_8254_wraparound;
> -wait_8254_wraparound is __init. wait_timer_tick should be __initdata,
> -which flows onto several other functions.
> -
> ->Error: ./arch/i386/kernel/cpu/mtrr/centaur.o .data refers to 00000008 R_386_32 .init.text
> -
> -That is real, centaur_mtrr_ops.init = centaur_mcr_init. Like a lot of
> -this initialization code, we get away with the dangling reference
> -because the code is only executed at boot.
> -
> ->Error: ./arch/i386/kernel/cpu/mtrr/centaur.o .eh_frame refers to 000000dc R_386_32 .init.text
> -
> -I don't see any .eh_frame references in 2.6.7-rc2 using gcc version
> -3.3.3 20040412 (Red Hat Linux 3.3.3-7). Where are they coming from?
> -
> ->Error: ./arch/i386/kernel/cpu/mtrr/cyrix.o .data refers to 00000028 R_386_32 .init.text
> -
> -Same as centaur.
> -
> ->Error: ./arch/i386/kernel/cpu/mtrr/generic.o .text refers to 0000038f R_386_32 .init.data
> -
> -arch/i386/kernel/cpu/mtrr/generic.c
> -generic_set_all() uses __intdata smp_changes_mask.
> -
> ->Error: ./arch/i386/kernel/smpboot.o .altinstructions refers to 00000000 R_386_32 .init.text
> -
> -altinstructions is a false positive, tweak reference_init.pl
> -
> ---- reference_init.pl.orig 2004-06-01 20:30:27.000000000 +1000
> -+++ reference_init.pl 2004-06-01 20:31:01.000000000 +1000
> -@@ -93,6 +93,7 @@
> - $from !~ /\.stab$/ &&
> - $from !~ /\.rodata$/ &&
> - $from !~ /\.text\.lock$/ &&
> -+ $from !~ /\.altinstructions$/ &&
> - $from !~ /\.debug_/)) {
> - printf("Error: %s %s refers to %s\n", $object, $from, $line);
> - }
> -
> -The rest of the warnings look real, apart from the strange eh_frame.
> +Code in wrong sections:
> +[http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=108640220401558]
> +Run `make buildcheck` to find offending code
>
> ----------------------------------------------------------------------
> From: Rusty Russell
> @@ -667,81 +449,15 @@
> From: Matt Domsch
> Sat Jul 24 10:51:04 PDT 2004
>
Copy of a mail:
> -Request for Patches
> -
> -The 2.6.x kernel includes a MODULE_VERSION() parameter for providing
> -one convenient way for all modules to state what *their* version is
> -(as opposed to the version of the larger kernel they're included in).
> -
> -I've started submitting patches to the subsystem maintainers to add
> -MODULE_VERSION() entries for drivers that I particularly care about,
> -and would appreciate assistance handling the others.
> -
> -For modules which display their version as a string somewhere via
> -printk, the preferred mechanism is:
> -
> -#define DRV_VERSION "1.0.0"
> -MODULE_VERSION(DRV_VERSION);
> -
> -One aspect of MODULE_VERSION I haven't tackled is re-formatting
> -existing versions into the preferred method as found in include/linux/module.h:
> -
> -/* Version of form [<epoch>:]<version>[-<extra-version>].
> - Or for CVS/RCS ID version, everything but the number is stripped.
> - <epoch>: A (small) unsigned integer which allows you to start
> - versions
> - anew. If not mentioned, it's zero. eg. "2:1.0" is after
> - "1:2.0".
> - <version>: The <version> may contain only alphanumerics and the
> - character `.'. Ordered by numeric sort for numeric parts,
> - ascii sort for ascii parts (as per RPM or DEB algorithm).
> - <extraversion>: Like <version>, but inserted for local
> - customizations, eg "rh3" or "rusty1".
> -*/
> -
> -I leave such reformatting up to each driver author and/or patch
> -submitter.
> -
> -Thanks,
> -Matt
> +Add MODULE_VERSION() to modules.
> +[http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=109068085714776]
>
> ----------------------------------------------------------------------
> From: Andi Kleen
> Date: Sun, 19 Dec 2004 20:09:03 +0100
>
Copy of a mail:
> -Here's a proposed janitor project if anybody is interested:
> -
> -The current gcc 4.0 snapshots include some more warnings in -Wall
> -and changed some existing ones which makes a kernel compilation quite noisy.
> -
> -The project would be to fix all these warnings.
> -
> -Short howto:
> -
> -Get
> -ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20041219/gcc-core-4.0-20041219.tar.bz2
> -
> -Untar it and compile with
> -
> -mkdir obj
> -../gcc-*/configure --disable-checking --enable-languages=c --prefix=/usr/local/gcc4
> -make bootstrap
> -<as root>
> -make install
> -
> -
> -Then compile an uptodate 2.6 kernel with:
> -
> -make allmodconfig
> -make CC=/usr/local/gcc4/bin/gcc 2>&1 | tee LOG
> -grep warning LOG
> -
> -You'll see lots of warnings in LOG. Fix them all and submit patches
> -through the usual janitor channels.
> -
> --Andi
> -
> -[thread at http://marc.theaimsgroup.com/?t=110348353800003&r=1&w=2]
> +Fix gcc 4 warnings.
> +[http://marc.theaimsgroup.com/?t=110348353800003]
>
> ----------------------------------------------------------------------
> From: Felipe W Damasio
Hope i didn't miss any.
Domen
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (2 preceding siblings ...)
2005-01-18 0:02 ` Domen Puncer
@ 2005-01-18 0:06 ` Alexey Dobriyan
2005-01-18 0:08 ` Randy.Dunlap
` (46 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Alexey Dobriyan @ 2005-01-18 0:06 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
On Tuesday 18 January 2005 01:11, Domen Puncer wrote:
> Removed some finished, invalid, duplicate entries.
> Replaced inline explanation with summary and URL to original post.
> Comments, objections to any change?
...
> +Fix gcc 4 warnings.
> +[http://marc.theaimsgroup.com/?t=110348353800003]
CONFIG_DEBUG_INFO=n wasn't mentioned at this thread.
Alexey
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (3 preceding siblings ...)
2005-01-18 0:06 ` Alexey Dobriyan
@ 2005-01-18 0:08 ` Randy.Dunlap
2005-01-18 0:15 ` Domen Puncer
` (45 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Randy.Dunlap @ 2005-01-18 0:08 UTC (permalink / raw)
To: kernel-janitors
Domen Puncer wrote:
> Hi.
>
> Removed some finished, invalid, duplicate entries.
> Replaced inline explanation with summary and URL to original post.
> Comments, objections to any change?
Here are 2 recent janitor suggestions from lkml:
http://lkml.org/lkml/2005/1/5/117
http://lkml.org/lkml/2005/1/17/94
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (4 preceding siblings ...)
2005-01-18 0:08 ` Randy.Dunlap
@ 2005-01-18 0:15 ` Domen Puncer
2005-01-18 3:12 ` Jim Nelson
` (44 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Domen Puncer @ 2005-01-18 0:15 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
On 18/01/05 03:03 +0200, Alexey Dobriyan wrote:
> On Tuesday 18 January 2005 01:11, Domen Puncer wrote:
>
> > Removed some finished, invalid, duplicate entries.
> > Replaced inline explanation with summary and URL to original post.
> > Comments, objections to any change?
>
> ...
>
> > +Fix gcc 4 warnings.
> > +[http://marc.theaimsgroup.com/?t=110348353800003]
>
> CONFIG_DEBUG_INFO=n wasn't mentioned at this thread.
No it wasn't.
It's used to make compiles faster, I assume?
I'll add a note.
Domen
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (5 preceding siblings ...)
2005-01-18 0:15 ` Domen Puncer
@ 2005-01-18 3:12 ` Jim Nelson
2005-01-18 5:03 ` Arnaldo Carvalho de Melo
` (43 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Jim Nelson @ 2005-01-18 3:12 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 673 bytes --]
Domen Puncer wrote:
> Hi.
>
> Removed some finished, invalid, duplicate entries.
> Replaced inline explanation with summary and URL to original post.
> Comments, objections to any change?
>
> Second stage, that i'm doing now is to put stuff into sections (like it
> is at the beginning of file).
> I'm also thinking about ordering from easiest to hardest.
> Ideas, comments?
>
>
>
An easy-to-hard sort would definitely make it easier for some newbie (like me) to
figure out what I can actually handle, and what I'm just going to batter my brains
bloody on.
Maybe something like a "Beginner", "Seasoned", and "Hard-core" skill ranking for
the entries. It'd help.
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (6 preceding siblings ...)
2005-01-18 3:12 ` Jim Nelson
@ 2005-01-18 5:03 ` Arnaldo Carvalho de Melo
2005-01-18 9:08 ` Alexey Dobriyan
` (42 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Arnaldo Carvalho de Melo @ 2005-01-18 5:03 UTC (permalink / raw)
To: kernel-janitors
Domen Puncer escreveu:
> Hi.
>
> Removed some finished, invalid, duplicate entries.
> Replaced inline explanation with summary and URL to original post.
> Comments, objections to any change?
>
> Second stage, that i'm doing now is to put stuff into sections (like it
> is at the beginning of file).
> I'm also thinking about ordering from easiest to hardest.
> Ideas, comments?
I suggest not removing the "finished stuff", just move them to a "finished
as of 2.6.something", as these cases may well come back in the future, say
when something big like infiniband gets merged it can come packed with
those "finished" things 8)
- Arnaldo
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (7 preceding siblings ...)
2005-01-18 5:03 ` Arnaldo Carvalho de Melo
@ 2005-01-18 9:08 ` Alexey Dobriyan
2005-01-18 14:06 ` Domen Puncer
` (41 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Alexey Dobriyan @ 2005-01-18 9:08 UTC (permalink / raw)
To: kernel-janitors
On Tuesday 18 January 2005 02:08, Randy.Dunlap wrote:
> Here are 2 recent janitor suggestions from lkml:
>
> http://lkml.org/lkml/2005/1/5/117
>
> http://lkml.org/lkml/2005/1/17/94
Another one:
http://marc.theaimsgroup.com/?t\x108001993000001&r=1&w=2
Macros in question are called DMA_32BIT_MASK and DMA_64BIT_MASK now.
Sample patch:
http://linux.bkbits.net:8080/linux-2.6/patch@1.1938.471.9?nav=cset@1.1938.471.9
Alexey
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (8 preceding siblings ...)
2005-01-18 9:08 ` Alexey Dobriyan
@ 2005-01-18 14:06 ` Domen Puncer
2005-01-18 14:25 ` Domen Puncer
` (40 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Domen Puncer @ 2005-01-18 14:06 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]
On 18/01/05 00:22 +0100, Michael Veeck wrote:
> Hi!
>
> I just wanted to check on how the general policy on maintaining patches
> is since I have done the min/max stuff and some still remain in the
> kernel. Mostly because the maintainers dont seem to incoporate them
> (isdn-eicorn for example was send nearly one year ago).
>
> So shall the remaining min/max stuff be left alone or should at least
> something be written into Documenteation/*.txt, maybe as a hint for
> future generations?
isdn was updated 11 month ago (!), some patches seem to got merged around
maintainers. As for min/max, i see 3 in -kj, none is isdn.
Maybe a list of files/dirs that are unmaintained / not worth patching?
Like:
drivers/isdn/
fs/devfs/
sound/oss/
broken drivers?
>
> As another easy task which might be useful for a newbie is to find other
> dupicate definitions. When looking myself for MinMax macros, I also
> stumbled over multiple ARRAY_SIZE().
>
> And then there is still the question if BIT(x) should be made general
> which also is defined multiple times.
Added those two.
> Domen Puncer schrieb:
> >Hi.
...
Please don't reply on top, and delete non relevant parts of message you
are replying to.
Domen
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (9 preceding siblings ...)
2005-01-18 14:06 ` Domen Puncer
@ 2005-01-18 14:25 ` Domen Puncer
2005-01-18 15:03 ` Matthew Wilcox
` (39 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Domen Puncer @ 2005-01-18 14:25 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
On 18/01/05 03:03 -0200, Arnaldo Carvalho de Melo wrote:
> Domen Puncer escreveu:
> >Hi.
> >
> >Removed some finished, invalid, duplicate entries.
> >Replaced inline explanation with summary and URL to original post.
> >Comments, objections to any change?
> >
> >Second stage, that i'm doing now is to put stuff into sections (like it
> >is at the beginning of file).
> >I'm also thinking about ordering from easiest to hardest.
> >Ideas, comments?
>
> I suggest not removing the "finished stuff", just move them to a "finished
> as of 2.6.something", as these cases may well come back in the future, say
> when something big like infiniband gets merged it can come packed with
> those "finished" things 8)
I'd normally agree, but most "finished stuff" here are specific issues
in specific files. The general ones are duplicates.
Domen
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (10 preceding siblings ...)
2005-01-18 14:25 ` Domen Puncer
@ 2005-01-18 15:03 ` Matthew Wilcox
2005-01-18 17:19 ` [openib-general] " Roland Dreier
` (38 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Matthew Wilcox @ 2005-01-18 15:03 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
On Tue, Jan 18, 2005 at 03:03:37AM -0200, Arnaldo Carvalho de Melo wrote:
> I suggest not removing the "finished stuff", just move them to a "finished
> as of 2.6.something", as these cases may well come back in the future, say
> when something big like infiniband gets merged it can come packed with
> those "finished" things 8)
Funny you should mention that.
drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
*SLAP*.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (11 preceding siblings ...)
2005-01-18 15:03 ` Matthew Wilcox
@ 2005-01-18 17:19 ` Roland Dreier
2005-01-18 17:34 ` Arnaldo Carvalho de Melo
` (37 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Roland Dreier @ 2005-01-18 17:19 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
Matthew> Funny you should mention that.
Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
Matthew> *SLAP*.
ouch ;)
What should those uses of yield() be replaced with? The loops are
polling for pending work to finish up on an exit path, and don't have
any strict timing requirements. cond_resched() seems a bit
heavyweight, since we don't need to run for our whole time slice. We
could do msleep(0) or msleep(1) but I don't quite see why that's much
of an improvement.
Thanks,
Roland
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (12 preceding siblings ...)
2005-01-18 17:19 ` [openib-general] " Roland Dreier
@ 2005-01-18 17:34 ` Arnaldo Carvalho de Melo
2005-01-18 17:45 ` [openib-general] " Nishanth Aravamudan
` (36 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Arnaldo Carvalho de Melo @ 2005-01-18 17:34 UTC (permalink / raw)
To: kernel-janitors
Matthew Wilcox escreveu:
> On Tue, Jan 18, 2005 at 03:03:37AM -0200, Arnaldo Carvalho de Melo wrote:
>
>>I suggest not removing the "finished stuff", just move them to a "finished
>>as of 2.6.something", as these cases may well come back in the future, say
>>when something big like infiniband gets merged it can come packed with
>>those "finished" things 8)
>
>
> Funny you should mention that.
>
> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
>
> *SLAP*.
See? 8)
- Arnaldo
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (13 preceding siblings ...)
2005-01-18 17:34 ` Arnaldo Carvalho de Melo
@ 2005-01-18 17:45 ` Nishanth Aravamudan
2005-01-18 18:05 ` Michael S. Tsirkin
` (35 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Nishanth Aravamudan @ 2005-01-18 17:45 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]
On Tue, Jan 18, 2005 at 09:19:40AM -0800, Roland Dreier wrote:
> Matthew> Funny you should mention that.
>
> Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
> Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
>
> Matthew> *SLAP*.
>
> ouch ;)
>
> What should those uses of yield() be replaced with? The loops are
> polling for pending work to finish up on an exit path, and don't have
> any strict timing requirements. cond_resched() seems a bit
> heavyweight, since we don't need to run for our whole time slice. We
> could do msleep(0) or msleep(1) but I don't quite see why that's much
> of an improvement.
I'm not an expert by any means, but I would *really* appreciate it if you would
not call msleep(0). Just because the function currently has the odd behavior of
sleeping for an extra jiffy, I don't want anyone to get the idea to call
msleep(0) in their drivers! :) It just seems misleading. Call msleep(1) if you
are ok with a millisecond delay (or longer). Currently it will sleep for a
millisecond + 1 jiffy, but hopefully we will eventually be able to implement
accurate delays, in which case it is most important that the intent of the
author (IMO masked by msleep(0)) be clear.
Thanks,
Nish
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (14 preceding siblings ...)
2005-01-18 17:45 ` [openib-general] " Nishanth Aravamudan
@ 2005-01-18 18:05 ` Michael S. Tsirkin
2005-01-18 18:10 ` Roland Dreier
` (34 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 18:05 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
Hello!
Quoting r. Roland Dreier (roland@topspin.com) "Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups":
> Matthew> Funny you should mention that.
>
> Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
> Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
>
> Matthew> *SLAP*.
>
> ouch ;)
>
> What should those uses of yield() be replaced with? The loops are
> polling for pending work to finish up on an exit path, and don't have
> any strict timing requirements. cond_resched() seems a bit
> heavyweight, since we don't need to run for our whole time slice. We
> could do msleep(0) or msleep(1) but I don't quite see why that's much
> of an improvement.
>
> Thanks,
> Roland
The reason we have this and not just closing the qp is because
we dont want to change the qp number, right?
May I put in again my proposal to add a "reset cq" verb, which will make
it possible to just reset everything when the interface is going down,
without polling, arbitrary timeouts and such.
I can build up a patch ...
MST
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (15 preceding siblings ...)
2005-01-18 18:05 ` Michael S. Tsirkin
@ 2005-01-18 18:10 ` Roland Dreier
2005-01-18 18:16 ` Michael S. Tsirkin
` (33 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Roland Dreier @ 2005-01-18 18:10 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
Michael> May I put in again my proposal to add a "reset cq" verb,
Michael> which will make it possible to just reset everything when
Michael> the interface is going down, without polling, arbitrary
Michael> timeouts and such.
I still don't understand how this resolves synchronization with
processing that may be in progress on other CPUs, etc.
Michael> I can build up a patch ...
Perhaps that would be the best way to explain the idea.
- R.
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (16 preceding siblings ...)
2005-01-18 18:10 ` Roland Dreier
@ 2005-01-18 18:16 ` Michael S. Tsirkin
2005-01-18 18:26 ` Matthew Wilcox
` (32 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 18:16 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
Hello!
Quoting r. Roland Dreier (roland@topspin.com) "Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups":
> Michael> May I put in again my proposal to add a "reset cq" verb,
> Michael> which will make it possible to just reset everything when
> Michael> the interface is going down, without polling, arbitrary
> Michael> timeouts and such.
>
> I still don't understand how this resolves synchronization with
> processing that may be in progress on other CPUs, etc.
By the way, I was looking at using RCU to reduce locking, also for
thing like poll_cq. What do you say to that?
> Michael> I can build up a patch ...
>
> Perhaps that would be the best way to explain the idea.
>
> - R.
okay
mst
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (17 preceding siblings ...)
2005-01-18 18:16 ` Michael S. Tsirkin
@ 2005-01-18 18:26 ` Matthew Wilcox
2005-01-18 18:29 ` Michael S. Tsirkin
` (31 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Matthew Wilcox @ 2005-01-18 18:26 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]
On Tue, Jan 18, 2005 at 09:19:40AM -0800, Roland Dreier wrote:
> Matthew> Funny you should mention that.
>
> Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
> Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
>
> Matthew> *SLAP*.
>
> ouch ;)
>
> What should those uses of yield() be replaced with? The loops are
> polling for pending work to finish up on an exit path, and don't have
> any strict timing requirements. cond_resched() seems a bit
> heavyweight, since we don't need to run for our whole time slice. We
> could do msleep(0) or msleep(1) but I don't quite see why that's much
> of an improvement.
The semantics of yield() aren't what you, or I, or 2.4 think they should
be. Basically, it means "go away, run anything else, even the idle task,
don't run me again for many seconds". I think msleep(1) is probably the
best for this driver, but I'm not sure exactly what semantics you want.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (18 preceding siblings ...)
2005-01-18 18:26 ` Matthew Wilcox
@ 2005-01-18 18:29 ` Michael S. Tsirkin
2005-01-18 19:06 ` Roland Dreier
` (30 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 18:29 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]
Hello!
Quoting r. Matthew Wilcox (matthew@wil.cx) "Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups":
> On Tue, Jan 18, 2005 at 09:19:40AM -0800, Roland Dreier wrote:
> > Matthew> Funny you should mention that.
> >
> > Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
> > Matthew> drivers/infiniband/ulp/ipoib/ipoib_ib.c: yield();
> >
> > Matthew> *SLAP*.
> >
> > ouch ;)
> >
> > What should those uses of yield() be replaced with? The loops are
> > polling for pending work to finish up on an exit path, and don't have
> > any strict timing requirements. cond_resched() seems a bit
> > heavyweight, since we don't need to run for our whole time slice. We
> > could do msleep(0) or msleep(1) but I don't quite see why that's much
> > of an improvement.
>
> The semantics of yield() aren't what you, or I, or 2.4 think they should
> be. Basically, it means "go away, run anything else, even the idle task,
> don't run me again for many seconds". I think msleep(1) is probably the
> best for this driver, but I'm not sure exactly what semantics you want.
We are brining the interface down, and are polling some locations
to check that it is safe to go away.
mst
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (19 preceding siblings ...)
2005-01-18 18:29 ` Michael S. Tsirkin
@ 2005-01-18 19:06 ` Roland Dreier
2005-01-18 19:07 ` Roland Dreier
` (29 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Roland Dreier @ 2005-01-18 19:06 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
Michael> By the way, I was looking at using RCU to reduce locking,
Michael> also for thing like poll_cq. What do you say to that?
Unless it's a dramatic speedup, we should avoid RCU because it seems
RCU can only be used with GPL code, not dual GPL/BSD.
- Roland
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (20 preceding siblings ...)
2005-01-18 19:06 ` Roland Dreier
@ 2005-01-18 19:07 ` Roland Dreier
2005-01-18 20:54 ` Jim Nelson
` (28 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Roland Dreier @ 2005-01-18 19:07 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
Matthew> The semantics of yield() aren't what you, or I, or 2.4
Matthew> think they should be. Basically, it means "go away, run
Matthew> anything else, even the idle task, don't run me again for
Matthew> many seconds". I think msleep(1) is probably the best
Matthew> for this driver, but I'm not sure exactly what semantics
Matthew> you want.
OK, I'll make that change. Thanks.
- Roland
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (21 preceding siblings ...)
2005-01-18 19:07 ` Roland Dreier
@ 2005-01-18 20:54 ` Jim Nelson
2005-01-20 17:02 ` [openib-general] " Adrian Bunk
` (27 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Jim Nelson @ 2005-01-18 20:54 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
Domen Puncer wrote:
> On 18/01/05 00:22 +0100, Michael Veeck wrote:
>
>>Hi!
>>
>>I just wanted to check on how the general policy on maintaining patches
>>is since I have done the min/max stuff and some still remain in the
>>kernel. Mostly because the maintainers dont seem to incoporate them
>>(isdn-eicorn for example was send nearly one year ago).
>>
>>So shall the remaining min/max stuff be left alone or should at least
>>something be written into Documenteation/*.txt, maybe as a hint for
>>future generations?
>
>
> isdn was updated 11 month ago (!), some patches seem to got merged around
> maintainers. As for min/max, i see 3 in -kj, none is isdn.
>
> Maybe a list of files/dirs that are unmaintained / not worth patching?
> Like:
> drivers/isdn/
> fs/devfs/
> sound/oss/
> broken drivers?
Could put broken drivers in the category "You've got the hardware, you make it
work".
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (22 preceding siblings ...)
2005-01-18 20:54 ` Jim Nelson
@ 2005-01-20 17:02 ` Adrian Bunk
2005-01-20 17:11 ` Greg KH
` (26 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Adrian Bunk @ 2005-01-20 17:02 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
On Tue, Jan 18, 2005 at 11:06:19AM -0800, Roland Dreier wrote:
> Michael> By the way, I was looking at using RCU to reduce locking,
> Michael> also for thing like poll_cq. What do you say to that?
>
> Unless it's a dramatic speedup, we should avoid RCU because it seems
> RCU can only be used with GPL code, not dual GPL/BSD.
"dual GPL/BSD" means you can choose whether you want to use the code
under the GPL or under a BSD licence.
Therefore, it's simply GPL code.
And even in the other case, the 3-clause BSD licence is compatible with
the GPL.
> - Roland
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
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (23 preceding siblings ...)
2005-01-20 17:02 ` [openib-general] " Adrian Bunk
@ 2005-01-20 17:11 ` Greg KH
2005-01-20 17:19 ` Grant Grundler
` (25 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Greg KH @ 2005-01-20 17:11 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
On Thu, Jan 20, 2005 at 06:02:36PM +0100, Adrian Bunk wrote:
> On Tue, Jan 18, 2005 at 11:06:19AM -0800, Roland Dreier wrote:
> > Michael> By the way, I was looking at using RCU to reduce locking,
> > Michael> also for thing like poll_cq. What do you say to that?
> >
> > Unless it's a dramatic speedup, we should avoid RCU because it seems
> > RCU can only be used with GPL code, not dual GPL/BSD.
>
> "dual GPL/BSD" means you can choose whether you want to use the code
> under the GPL or under a BSD licence.
>
> Therefore, it's simply GPL code.
Sure, but then no one can then take that code and use it under the BSD
license in the future, due to the dependancy on the RCU code, which is
_only_ allowed to be used under the GPL.
That's the main reason the openib people object to this, it has nothing
to do with the in-kernel code at all.
Personally, I think it's a stupid thing to try to license this code in a
dual way, as any port someone is going to have to do to get this code to
work in another os will be almost a complete rewrite in the end
anyway...
thanks,
greg k-h
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (24 preceding siblings ...)
2005-01-20 17:11 ` Greg KH
@ 2005-01-20 17:19 ` Grant Grundler
2005-01-20 18:02 ` Sean Hefty
` (24 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Grant Grundler @ 2005-01-20 17:19 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
On Thu, Jan 20, 2005 at 06:02:36PM +0100, Adrian Bunk wrote:
> On Tue, Jan 18, 2005 at 11:06:19AM -0800, Roland Dreier wrote:
> > Michael> By the way, I was looking at using RCU to reduce locking,
> > Michael> also for thing like poll_cq. What do you say to that?
> >
> > Unless it's a dramatic speedup, we should avoid RCU because it seems
> > RCU can only be used with GPL code, not dual GPL/BSD.
>
> "dual GPL/BSD" means you can choose whether you want to use the code
> under the GPL or under a BSD licence.
>
> Therefore, it's simply GPL code.
Adrian,
I think you overlooked the fact that include/linux/rcupdate.h is published
under the GPL. Not "dual GPL/BSD". Someone can't take code that uses
linux's RCU and ship it under a BSD license.
There are "consumers" of openib.org that want to do that.
ergo we can't use RCU unless they are willing to give that up.
> And even in the other case, the 3-clause BSD licence is compatible with
> the GPL.
Sorry - I'm no lawyer. I've never heard of "3-clause BSD" and that's
probably a good thing. I fail to see the point of something that's
compatible with GPL since one could just use GPL in that case.
grant
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (25 preceding siblings ...)
2005-01-20 17:19 ` Grant Grundler
@ 2005-01-20 18:02 ` Sean Hefty
2005-01-20 18:21 ` Greg KH
` (23 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Sean Hefty @ 2005-01-20 18:02 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
Greg KH wrote:
> Personally, I think it's a stupid thing to try to license this code in a
> dual way, as any port someone is going to have to do to get this code to
> work in another os will be almost a complete rewrite in the end
> anyway...
I think that companies want to be able to make derivative works without
needing to make the derivative open source, versus porting it to
another OS.
- Sean
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (26 preceding siblings ...)
2005-01-20 18:02 ` Sean Hefty
@ 2005-01-20 18:21 ` Greg KH
2005-01-20 18:27 ` Sean Hefty
` (22 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Greg KH @ 2005-01-20 18:21 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
On Thu, Jan 20, 2005 at 10:02:24AM -0800, Sean Hefty wrote:
> Greg KH wrote:
>
> >Personally, I think it's a stupid thing to try to license this code in a
> >dual way, as any port someone is going to have to do to get this code to
> >work in another os will be almost a complete rewrite in the end
> >anyway...
>
> I think that companies want to be able to make derivative works without
> needing to make the derivative open source, versus porting it to
> another OS.
And then run that derivitave work on a Linux GPL kernel? Hah, good luck
with your lawyers if you try to do that. And good luck trying to work
around symbols that the openib code is using that are marked
EXPORT_SYMBOL_GPL().
Why do people try to do such stupid things, haven't the IB members
learned from the past...
Remind me to _never_ send in an openib kernel patch if this is the
reason why the license is what it is.
bleah.
greg k-h
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (27 preceding siblings ...)
2005-01-20 18:21 ` Greg KH
@ 2005-01-20 18:27 ` Sean Hefty
2005-01-21 4:35 ` Ronald G. Minnich
` (21 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Sean Hefty @ 2005-01-20 18:27 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
Greg KH wrote:
>>>Personally, I think it's a stupid thing to try to license this code in a
>>>dual way, as any port someone is going to have to do to get this code to
>>>work in another os will be almost a complete rewrite in the end
>>>anyway...
>>
>>I think that companies want to be able to make derivative works without
>>needing to make the derivative open source, versus porting it to
>>another OS.
>
> And then run that derivitave work on a Linux GPL kernel? Hah, good luck
> with your lawyers if you try to do that. And good luck trying to work
> around symbols that the openib code is using that are marked
> EXPORT_SYMBOL_GPL().
>
> Why do people try to do such stupid things, haven't the IB members
> learned from the past...
I'm not criticizing or defending this, just guessing the reason for the
dual license.
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (28 preceding siblings ...)
2005-01-20 18:27 ` Sean Hefty
@ 2005-01-21 4:35 ` Ronald G. Minnich
2005-01-21 6:48 ` Greg KH
` (20 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Ronald G. Minnich @ 2005-01-21 4:35 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: TEXT/PLAIN, Size: 807 bytes --]
On Thu, 20 Jan 2005, Grant Grundler wrote:
> I think you overlooked the fact that include/linux/rcupdate.h is
> published under the GPL. Not "dual GPL/BSD". Someone can't take code
> that uses linux's RCU and ship it under a BSD license. There are
> "consumers" of openib.org that want to do that. ergo we can't use RCU
> unless they are willing to give that up.
Does this open up the possibility of a GPL-only "fork" in the code, i.e.
somebody:
- takes the code, and puts it in another repo somewhere
- adds in RCU
- makes it available to others but only under GPL due to RCU inclusion
- now we have an openib fork that is GPL by definition, that can't be
BSD due to inclusion of RCU?
Seems almost inevitable as soon as people really want "Feature XYZ" from
Linux in their openib code base.
ron
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (29 preceding siblings ...)
2005-01-21 4:35 ` Ronald G. Minnich
@ 2005-01-21 6:48 ` Greg KH
2005-01-21 16:20 ` Woodruff, Robert J
` (19 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Greg KH @ 2005-01-21 6:48 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On Thu, Jan 20, 2005 at 09:35:59PM -0700, Ronald G. Minnich wrote:
> On Thu, 20 Jan 2005, Grant Grundler wrote:
> > I think you overlooked the fact that include/linux/rcupdate.h is
> > published under the GPL. Not "dual GPL/BSD". Someone can't take code
> > that uses linux's RCU and ship it under a BSD license. There are
> > "consumers" of openib.org that want to do that. ergo we can't use RCU
> > unless they are willing to give that up.
>
> Does this open up the possibility of a GPL-only "fork" in the code, i.e.
> somebody:
> - takes the code, and puts it in another repo somewhere
> - adds in RCU
> - makes it available to others but only under GPL due to RCU inclusion
> - now we have an openib fork that is GPL by definition, that can't be
> BSD due to inclusion of RCU?
Or:
- someone gets a GPL only license file added to the openib code
base in the linux kernel, by slipping it in through another
path to Linus.
Odds are, that's going to happen before the above does :)
Remember, the openib code uses functions that are marked
EXPORT_SYMBOL_GPL() and if _anyone_ violates those markings by trying to
ship a openib derivative work with a non-gpl license, they will be hearing
from some lawyers very quickly.
> Seems almost inevitable as soon as people really want "Feature XYZ" from
> Linux in their openib code base.
And as more and more "feature xyz" in the kernel are being marked GPL
only, it's only a matter of time...
greg k-h
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* RE: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (30 preceding siblings ...)
2005-01-21 6:48 ` Greg KH
@ 2005-01-21 16:20 ` Woodruff, Robert J
2005-01-21 16:56 ` Roland Dreier
` (18 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Woodruff, Robert J @ 2005-01-21 16:20 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Ron>Does this open up the possibility of a GPL-only "fork" in the code,
i.e.
>somebody:
This actually brings up an even bigger question.
When the kernel folks accepted the code into the kernel, which license
did they choose ? The BSD license or the GPL license ?
If it was the GPL license, then the code that is in
kernel.org is the GPL-only fork.
woody
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (31 preceding siblings ...)
2005-01-21 16:20 ` Woodruff, Robert J
@ 2005-01-21 16:56 ` Roland Dreier
2005-01-21 17:07 ` Woodruff, Robert J
` (17 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Roland Dreier @ 2005-01-21 16:56 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]
Robert> This actually brings up an even bigger question. When the
Robert> kernel folks accepted the code into the kernel, which
Robert> license did they choose ? The BSD license or the GPL
Robert> license ? If it was the GPL license, then the code that is
Robert> in kernel.org is the GPL-only fork.
The code in the kernel has the same license headers as the subversion
tree: dual GPL/BSD.
- Roland
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* RE: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (32 preceding siblings ...)
2005-01-21 16:56 ` Roland Dreier
@ 2005-01-21 17:07 ` Woodruff, Robert J
2005-01-21 17:15 ` Ronald G. Minnich
` (16 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Woodruff, Robert J @ 2005-01-21 17:07 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
Roland wrote>The code in the kernel has the same license headers as the
subversion
>tree: dual GPL/BSD.
Here is the text I see in the headers:
"* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
* General Public License (GPL) Version 2, available from the file
* COPYING in the main directory of this source tree, or the
* OpenIB.org BSD license below:"
This tells me that when the kernel.org people accepted the code into the
kernel, they needed to accept it under one of the two licenses,
GPL or BSD. Or am I missing something here ?
I think they could have accepted it under BSD and then re-license it
under
the same dual license if they wanted, but I am not a lawyer.
woody
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* RE: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (33 preceding siblings ...)
2005-01-21 17:07 ` Woodruff, Robert J
@ 2005-01-21 17:15 ` Ronald G. Minnich
2005-01-21 17:22 ` Roland Dreier
` (15 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Ronald G. Minnich @ 2005-01-21 17:15 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: TEXT/PLAIN, Size: 337 bytes --]
On Fri, 21 Jan 2005, Woodruff, Robert J wrote:
> If it was the GPL license, then the code that is in
> kernel.org is the GPL-only fork.
this keeps getting more and more interesting. For example, now that the
code is in the kernel, is there any need to maintain the openib tree?
that code in the kernel is GPL, period, right?
ron
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (34 preceding siblings ...)
2005-01-21 17:15 ` Ronald G. Minnich
@ 2005-01-21 17:22 ` Roland Dreier
2005-01-21 17:24 ` Matt Leininger
` (14 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Roland Dreier @ 2005-01-21 17:22 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
Ronald> this keeps getting more and more interesting. For example,
Ronald> now that the code is in the kernel, is there any need to
Ronald> maintain the openib tree?
Independent of any licensing questions, there definitely is a real
need to have an external repository for development. We need a place
to test and debug code and coordinate development before sending
patches on.
(I am beginning to think that it would just be simpler to make all the
openib kernel code simply GPLed, if only to stop these constant
discussions. Perhaps at the developers workshop, the openib board can
make this change)
- Roland
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (35 preceding siblings ...)
2005-01-21 17:22 ` Roland Dreier
@ 2005-01-21 17:24 ` Matt Leininger
2005-01-21 17:57 ` Libor Michalek
` (13 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Matt Leininger @ 2005-01-21 17:24 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
On Thu, 2005-01-20 at 10:21 -0800, Greg KH wrote:
> On Thu, Jan 20, 2005 at 10:02:24AM -0800, Sean Hefty wrote:
> > Greg KH wrote:
> >
> > >Personally, I think it's a stupid thing to try to license this code in a
> > >dual way, as any port someone is going to have to do to get this code to
> > >work in another os will be almost a complete rewrite in the end
> > >anyway...
> >
> > I think that companies want to be able to make derivative works without
> > needing to make the derivative open source, versus porting it to
> > another OS.
>
> And then run that derivitave work on a Linux GPL kernel? Hah, good luck
> with your lawyers if you try to do that. And good luck trying to work
> around symbols that the openib code is using that are marked
> EXPORT_SYMBOL_GPL().
>
> Why do people try to do such stupid things, haven't the IB members
> learned from the past...
>
> Remind me to _never_ send in an openib kernel patch if this is the
> reason why the license is what it is.
>
The idea was for folks to be able to take the OpenIB code, under BSD,
and port it to OSes other than Linux. I agree that having a BSD only
stack running on Linux would be silly and should be avoided. In the end
I only care about Linux. I think performance should drive what Linux
features OpenIB uses. If it improves performance then it's worth
using.
- Matt
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (36 preceding siblings ...)
2005-01-21 17:24 ` Matt Leininger
@ 2005-01-21 17:57 ` Libor Michalek
2005-01-21 19:32 ` Grant Grundler
` (12 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Libor Michalek @ 2005-01-21 17:57 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
On Fri, Jan 21, 2005 at 09:22:56AM -0800, Roland Dreier wrote:
> Ronald> this keeps getting more and more interesting. For example,
> Ronald> now that the code is in the kernel, is there any need to
> Ronald> maintain the openib tree?
>
> Independent of any licensing questions, there definitely is a real
> need to have an external repository for development. We need a place
> to test and debug code and coordinate development before sending
> patches on.
Plus there is software which interacts with the OpenIB kernel code,
that is not intended or appropriate for kernel submission. (e.q. user
space access, OpenSM, etc.)
I seem to remember that the license was the result of getting the
member companies to open their exisiting software. There was concern
since some of that software was already licensed to third parties
under non-GPL licenses. I think we can certainly revisit the issue
for all the gen2 software which is being written from scratch.
-Libor
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (37 preceding siblings ...)
2005-01-21 17:57 ` Libor Michalek
@ 2005-01-21 19:32 ` Grant Grundler
2005-01-21 19:33 ` Grant Grundler
` (11 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Grant Grundler @ 2005-01-21 19:32 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
On Fri, Jan 21, 2005 at 09:22:56AM -0800, Roland Dreier wrote:
> Independent of any licensing questions, there definitely is a real
> need to have an external repository for development. We need a place
> to test and debug code and coordinate development before sending
> patches on.
Agreed
> (I am beginning to think that it would just be simpler to make all the
> openib kernel code simply GPLed, if only to stop these constant
> discussions. Perhaps at the developers workshop, the openib board can
> make this change)
then someone will whine about not being able to port the
code to FreeBSD. Either way - someone will whine.
If we can, I would prefer to leave the license Dual and then deal
with the people who try to violate the GPL. My gut feeling is
such people don't care which license the code is published with.
grant
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [openib-general] Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (38 preceding siblings ...)
2005-01-21 19:32 ` Grant Grundler
@ 2005-01-21 19:33 ` Grant Grundler
2005-01-24 23:32 ` Randy.Dunlap
` (10 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Grant Grundler @ 2005-01-21 19:33 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 196 bytes --]
On Fri, Jan 21, 2005 at 10:15:47AM -0700, Ronald G. Minnich wrote:
> that code in the kernel is GPL, period, right?
No. The default license is GPL if none is specified in the source file.
grant
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (39 preceding siblings ...)
2005-01-21 19:33 ` Grant Grundler
@ 2005-01-24 23:32 ` Randy.Dunlap
2005-01-24 23:42 ` Randy.Dunlap
` (9 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Randy.Dunlap @ 2005-01-24 23:32 UTC (permalink / raw)
To: kernel-janitors
Domen Puncer wrote:
> Hi.
>
> Removed some finished, invalid, duplicate entries.
> Replaced inline explanation with summary and URL to original post.
> Comments, objections to any change?
>
> Second stage, that i'm doing now is to put stuff into sections (like it
> is at the beginning of file).
> I'm also thinking about ordering from easiest to hardest.
> Ideas, comments?
This one:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From Linus:
Check stack usage and reduce it in the worst cases.
See: http://bugme.osdl.org/show_bug.cgi?id86
There is another script that checks function stack usage at
http://kernelnewbies.org/scripts/ .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
should be changed to something like (with edits if/as you prefer):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use a series of commands like (e.g.)
make allmodconfig
make all
make checkstack >stack.report
and then look at 'stack.report' and search for large
stack users. Generally, if a function uses more than
around 1000 bytes of stack space, it should be considered
for stack reduction by some appropriate means (where
'appropriate' varies depending on some analysis, such as
code review or dumping object code), either by dynamic allocation
of (current) on-stack structures, un-inlining some functions
whose combined stack sizes add up, moving parts of functions
that declare data to separate functions, or some other means.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (40 preceding siblings ...)
2005-01-24 23:32 ` Randy.Dunlap
@ 2005-01-24 23:42 ` Randy.Dunlap
2005-01-24 23:47 ` Randy.Dunlap
` (8 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Randy.Dunlap @ 2005-01-24 23:42 UTC (permalink / raw)
To: kernel-janitors
Domen Puncer wrote:
> Hi.
>
> Removed some finished, invalid, duplicate entries.
> Replaced inline explanation with summary and URL to original post.
> Comments, objections to any change?
>
> Second stage, that i'm doing now is to put stuff into sections (like it
> is at the beginning of file).
> I'm also thinking about ordering from easiest to hardest.
> Ideas, comments?
> -------------------------------------------------------------------------
> For source files that don't have any license information in them,
> determine if they should be GPL or GPL/BSD etc. and add license information
> to them.
We don't really want a blanket set of patches for this one.
If a file is being modified anyway, it's probably a good idea to
update the license info in it (but check with the author(s) first
for the exact license that they prefer).
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (41 preceding siblings ...)
2005-01-24 23:42 ` Randy.Dunlap
@ 2005-01-24 23:47 ` Randy.Dunlap
2005-01-25 14:28 ` Domen Puncer
` (7 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Randy.Dunlap @ 2005-01-24 23:47 UTC (permalink / raw)
To: kernel-janitors
Domen Puncer wrote:
> ------------------------------------------------------------------------
> -From: Keith Owens
> -To: Andrew Morton
> -Subject: Re: Latest reference_init.pl script
> -
> ->Error: ./arch/i386/kernel/smpboot.o .altinstructions refers to 00000000 R_386_32 .init.text
> -
> -altinstructions is a false positive, tweak reference_init.pl
> -
> ---- reference_init.pl.orig 2004-06-01 20:30:27.000000000 +1000
> -+++ reference_init.pl 2004-06-01 20:31:01.000000000 +1000
> -@@ -93,6 +93,7 @@
> - $from !~ /\.stab$/ &&
> - $from !~ /\.rodata$/ &&
> - $from !~ /\.text\.lock$/ &&
> -+ $from !~ /\.altinstructions$/ &&
> - $from !~ /\.debug_/)) {
> - printf("Error: %s %s refers to %s\n", $object, $from, $line);
> - }
This patch to reference_init.pl can be removed. It has already
been merged.
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (42 preceding siblings ...)
2005-01-24 23:47 ` Randy.Dunlap
@ 2005-01-25 14:28 ` Domen Puncer
2005-01-25 16:58 ` Randy.Dunlap
` (6 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Domen Puncer @ 2005-01-25 14:28 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 21848 bytes --]
On 18/01/05 00:11 +0100, Domen Puncer wrote:
> Hi.
>
> Second stage, that i'm doing now is to put stuff into sections (like it
> is at the beginning of file).
> I'm also thinking about ordering from easiest to hardest.
I tried doing this, diff is ugly, lots of reordering, moving and
making items from below shorter. Easiest to hardest ordering is very
rough and subjective.
I think i added all new suggestions.
Deleted rcpci45.c and module licences entries.
So... is it better, or should i just continue with previous version?
Domen
--- TODO-1.26 2005-01-17 23:55:27.000000000 +0100
+++ TODO-1.27 2005-01-25 15:15:35.000000000 +0100
@@ -3,15 +3,24 @@
$Id: TODO,v 1.25 2004/12/29 23:03:14 domen Exp $
-===================-
-None of the following items are in any order of importance or difficulty.
-Where possible related items have been grouped together.
+Send patches that add/fix items to kernel-janitors@lists.osdl.org.
+Please don't add items to end of file.
-Before attacking any of these, we suggest that you ask about it (them)
-on the mailing list (kernel-janitors at lists.osdl.org).
+Before attacking any of these, we suggest sending a few patches in
+advance to see if you are doing something wrong, or if someone else
+is already doing same work.
Read related threads in the mailing list archive.
+Where it makes sense, sections are supposed to be ordered by incresing
+difficulty.
+
+Links are marked with:
+D: description/information about the issue
+E: example patch
+
--------------------------------------------------------------------------
NOTE: scripts/kj.pl was a weekend hack. Don't take it too seriously.
+- add more checks to kj.pl
--------------------------------------------------------------------------
Audit return codes (and handle failure correctly) for..
@@ -26,6 +35,11 @@
Some code tests mapping for a non-zero value, which is incorrect.
- __get_free_pages() and __get_free_page()
- ioremap() -- Some are using this as a pointer, which is wrong.
+- put/get_user()
+- copy_*_user(), unlike put_user() it returns number of bytes failed to copy
+- kernel_thread()
+- IDE drivers, as it can cause a real problem:
+ [D: http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=110416923101031]
-----------------------------------------------------------------------------
Balancing functions.
@@ -42,13 +56,28 @@
-----------------------------------------------------------------------------
Remove unneeded historic code / New API conversions.
+- Code that depends on LINUX_VERSION_CODE & KERNEL_VERSION < 2.4 can be
+ deleted in most cases.
- checking for NULL on probe routines for net drivers
+- get rid of init_module / cleanup_module
+- call SET_MODULE_OWNER or use .owner = THIS_MODULE instead of using
+ MOD_{INC,DEC}_USE_COUNT (only a few remain)
+- Use pci_set_drvdata() to set dev->driver_data, likewise use pci_get_drvdata()
+ instead of reading directly.
+ - dev->driver_data = pcigame;
+ + pci_set_drvdata(dev, pcigame);
+- get rid of verify_area with copy_*_user get/put_user, only needed if
+ using __copy_*_user et al
+- MODULE_PARM must die:
+ [D: http://marc.theaimsgroup.com/?l=linux-kernel&m=109826168201622&w=2]
+ [E: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm2/broken-out/remove-module_parm-from-allyesconfig-almost.patch]
+- Add MODULE_VERSION() to modules.
+ [D: http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=109068085714776]
- convert drivers to new PCI API
- get rid of check_region, use just request_region checking its return (2.2
request_region returned void) and now the driver init sequence is not to be
serialized anymore, so races are possible (look at cardbus/pcihotplug code)
- http://lists.osdl.org/pipermail/kernel-janitors/2004-January/000346.html
-- converting cli to spinlocks (look at net/netrom/*.c, etc)
+ [D: http://lists.osdl.org/pipermail/kernel-janitors/2004-January/000346.html]
- ALL PCI drivers should call pci_enable_device --before-- reading
pdev->irq or pdev->resource[]. irq and resource[] may not have correct
values until after PCI hotplug setup occurs at pci_enable_device()
@@ -56,27 +85,106 @@
Many of these fixed already at:
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-11/0150.html
FIXME: Dead URL!
-- Purely cosmetic, but far nicer to read..
+- convert cli/sti/save_flags/save_flags_cli/restore_flags usage to
+ accepted locking primitives;
+ see Documentation/cli-sti-removal.txt and Documentation/spinlocks.txt
+ for details.
+ [E: http://linux.bkbits.net:8080/linux-2.6/cset@419b78fcaLKtZt39OF_dslTbk-b3KQ?nav=index.html|ChangeSet@-8w]
+- yield() considered harmful:
+ [D: http://marc.theaimsgroup.com/?t=106554796200005]
+ Don't forget to set_current_state(TASK_{,UN}INTERRUPTIBLE); before
+ schedule*().
+ Consider using msleep();.
+- Anything which uses sleep_on*() has a 90% chance of being broken. Fix
+ them all, because we want to remove sleep_on() and friends in 2.5.
+ [D: http://boudicca.tux.org/hypermail/linux-kernel/2001week05/0305.html]
+ Be sure to read replies too.
+- Replace (un)register_ioctl32_conversion with ioctl_compat:
+ [D: http://lkml.org/lkml/2005/1/5/106]
+
+-----------------------------------------------------------------------------
+- clean up Documentation/DocBook/ , fix warnings that occur on make *docs.
+- printk() calls should include appropriate KERN_* constant (of course
+ only at beginning of lines).
+ [E: http://linux.bkbits.net:8080/linux-2.5/patch@1.1555]
+ Example how to _not_ do it, fix it:
+ http://linux.bkbits.net:8080/linux-2.5/patch@1.1938.165.103
+- pr_debug() from kernel.h could replace a lot of DPRINTK and similar macros.
+- same for pr_info()
+- Lots of unnecessary casts in drivers can be removed.
+ Example:
+ - struct netdev_private *np = (struct netdev_private *)dev->priv;
+ + struct netdev_private *np = dev->priv;
+- min/max macros from kernel.h are safe, a lot of handcrafted MIN/MAX are not.
+- ARRAY_SIZE macro has duplicates, remove them.
+- put BIT macro into kernel.h (?) and remove it from drivers
+- remove string concatenation with __FUNCTION__ (get rid of
+ warnings, and get ready for __func__):
+ - printk(KERN_INFO "blabla " __FUNCTION__ "\n");
+ + printk(KERN_INFO "blabla %s\n", __FUNCTION__);
+- uninitialize static variables initialized to 0, to make it go to the .bss,
+ instead of .data.
+ __initdata has to be initialized, even if to 0 though.
+- Purely cosmetic, but far nicer to read.
- for (list = ymf_devs.next; list != &ymf_devs; list = list->next) {
+ list_for_each(list, &ymf_devs) {
-- Use pci_set_drvdata() to set dev->driver_data, likewise use pci_get_drvdata()
- instead of reading directly.
- - dev->driver_data = pcigame;
- + pci_set_drvdata(dev, pcigame);
+- make non-global functions static.
+- preferred string form (include outputs from `size` in patch description)
+ - [const] char *foo = "blah";
+ + [const] char foo[] = "blah";
+ [D: http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=105849621011469]
+- convert all explicit lock initializations to spin_lock_init() or
+ rwlock_init(). (Besides consistency this also helps automatic lock
+ validators and debugging code.)
+ [D: http://lwn.net/Articles/109505/]
+ [E: http://linux.bkbits.net:8080/linux-2.6/cset@419a6f292wHnthuDzw7VfgECNLmvLg?nav=index.html|ChangeSet@-8w]
+- fix warnings/errors
+ [D: http://developer.osdl.org/~cherry/compile/]
+ [D: http://www.osdl.org/projects/26lnxstblztn/results/]
+- pci_set_dma_mask() and friends should use DMA_{32,64}BIT_MASK instead of
+ 0xffff...
+ [D: http://marc.theaimsgroup.com/?t=108001993000001]
+ [E: http://linux.bkbits.net:8080/linux-2.6/patch@1.1938.471.9]
+- check kmallocs for things like GFP_DMA without a memtype.
+- check that a freed pointer (*kfree_*) is not used again.
+- make sure BUG() is used correctly (i.e. if(function()) BUG(); is evil)
+ i.e. even when no-op-ing BUG we still have an if (See also: BUG_ON)
+- Code in wrong sections (ie. __init code called from __exit):
+ Run `make buildcheck` to find offending code.
+ (read_eeprom in net drivers is a good candidate for __init)
+ [D: http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=108640220401558]
+- Fix gcc 4 warnings.
+ [D: http://marc.theaimsgroup.com/?t=110348353800003]
+ Note: Set CONFIG_DEBUG_INFO=n to make compiles faster and smaller.
+- Audit all memcpy and memmove calls.
+ If areas overlap memmove should be used, if they don't memcpy.
+- drivers/char/i8k.c duplicates arch/i386/kernel/dmi_scan.c
+ Better would be to have dmi_scan.c set a flag which the i8k driver checks.
+- sleeping functions should not be called in interrupts or under spinlocks:
+ copy_to/from_user(), put/get_user(), schedule(), kmalloc()
+ except for GPF_ATOMIC, functions with __might_sleep() in body...
+- go through all the tty/serial drivers and make sure they don't give out
+ excessively useful information to non CAP_SYS_RAWIO users, then loosen
+ permissions. [D: http://lkml.org/lkml/2005/1/17/94]
+- check for dev_close calls without rntl_lock held (causes assertion
+ failures).
+- timer_del() vs. timer_del_sync()
+ [D: http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html]
+ A lot of the timer deletion races are hard to fix because of
+ the deadlock problem.
+- fix watchdog drivers to use link order rather than explicit
+ initialization calls (i810 is particularly broken)
+- check stack usage (make checkstack) and reduce it in the worst cases.
+ [D: http://bugme.osdl.org/show_bug.cgi?id=386]
+ [D: http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=110661227615538]
-----------------------------------------------------------------------------
-Copying to/from userspace issues.
-- The copy_*_user() routines may sleep.
- For this reason, they shouldn't be called with locks held, or with
- interrupts disabled.
-- get rid of verify_area with copy_*_user get/put_user, only needed if
- using __copy_*_user et al
-- make sure that copy_*_user return values are checked
-- use "return copy_*_user(...) ? -EFAULT : ok_value;"
-
SUSPECTS:
+copy_to/from_user:
- look at drivers/char/n_tty.c
+
+Items with longer description in no particular order:
-----------------------------------------------------------------------------
- get rid of isa_read/write[bwl], use ioremap instead
- unsigned long addr = 0xC0000;
@@ -128,15 +236,6 @@
one allocation fails, but others succeeded.
-----------------------------------------------------------------------------
-- fix watchdog drivers to use link order rather than explicit
- initialization calls (i810 is particularly broken)
-
-- get rid of init_module / cleanup_module (softdog in particular)
-
-- make sure BUG() is used correctly (i.e. if(function()) BUG(); is evil)
- i.e. even when no-op-ing BUG we still have an if (See also: BUG_ON)
-
------------------------------------------------------------------------------
From: Hans Grobler <grobh at sun dot ac dot za>
- audit an ioctl function to make sure there is no way a user can crash
@@ -146,30 +245,6 @@
ioctls are covered by the parent ioctl function (these can be nested to
great depths).
-- check for dev_close calls without rntl_lock held (cases assertion
- failures).
-
-- check that a freed pointer (*kfree_*) is not used again.
-
------------------------------------------------------------------------------
-From: David Woodhouse <dwmw2 at infradead dot org>
-
-- Anything which uses sleep_on*() has a 90% chance of being broken. Fix
- them all, because we want to remove sleep_on() and friends in 2.5.
-
-lkml thread at:
-http://boudicca.tux.org/hypermail/linux-kernel/2001week05/0305.html
-Be sure to read replies too.
-
------------------------------------------------------------------------------
-From: Andrew Morton <andrewm at uow dot edu dot au>
-
-Here - have about 300 bugs:
-
- http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
-
-A lot of the timer deletion races are hard to fix because of
-the deadlock problem.
-----------------------------------------------------------------------------
Date: Mon, 26 Feb 2001 16:53:50 -0800 (PST)
@@ -212,39 +287,11 @@
CONFIG_ISAPNP -or- CONFIG_ISAPNP_MODULE is defined.
------------------------------------------------------------------------
-From: Jeff Garzik <jgarzik at mandrakesoft dot com>
-
-Audit all memcpy and memmove calls.
-
-If calling memmove, see if the areas ever overlap.
-If not, use memcpy instead.
-
-If calling memcpy, see if the areas ever overlap.
-If so, use memmmove instead.
-
-------------------------------------------------------------------------
-From: Andrey Panin <pazke at orbita dot don dot sitek dot net>
-
-- check printk() calls (should include appropriate KERN_* constant).
-
-------------------------------------------------------------------------
From Dave Jones <davej at suse dot de>
- Lots of drivers are doing evil looking things writing to PCI_CACHE_LINE_SIZE
This should be done during PCI initialisation.
-- Checking LINUX_VERSION_CODE & KERNEL_VERSION for specific versions of
- 2.3 should be checked.
-
-- Lots of unnecessary casts in drivers can be removed.
- Example:
- - struct netdev_private *np = (struct netdev_private *)dev->priv;
- + struct netdev_private *np = dev->priv;
- Patch for a lot of these is available from
- ftp.suse.com/pub/people/davej/kernel/2.4/2.4.2ac20/unneeded-net-casts.diff
-
-- drivers/net/aironet*.c could use some functions being made statics.
-
- Many drivers have alignments such as..
dev->priv = (void *)(((unsigned long)dev->priv + 7) & ~7);
jgarzik:
@@ -254,10 +301,6 @@
for dev->priv, and since they are DMA'ing into dev->priv, they have to
do things manually.
-- drivers/net/rcpci45.c
- Quiten debug printk's in RCioctl()
-
-- Check kmallocs for things like GFP_DMA without a memtype.
- Signedness issues. We have _lots_ of these.
Adding a -W to the kernel build line shows them. We have lots of code paths
@@ -270,49 +313,11 @@
------------------------------------------------------------------------
From: Jeff Garzik <jgarzik at mandrakesoft dot com>
-read_eeprom can be marked __init in other net drivers also.
-
-akpm: well, not blindly, of course. Need to follow the call graph,
- make sure it's safe.
-
-------------------------------------------------------------------------
-From: Jeff Garzik <jgarzik at mandrakesoft dot com>
-
-The string form
-
- [const] char *foo = "blah";
-
-creates two variables in the final assembly output, a static string, and
-a char pointer to the static string. The alternate string form
-
- [const] char foo[] = "blah";
-
-is better because it declares a single variable.
-
-For variables marked __initdata, the "*foo" form causes only the
-pointer, not the string itself, to be dropped from the kernel image,
-which is a bug. Using the "foo[]" form with regular 'ole local
-variables also makes the assembly shorter.
-
-Look at the diff between include/linux/etherdevice.h in pre7 versus
-pre8. The assembly for the pre8 version is ~10 lines shorter, with 6 of
-those removed lines being the string constant stored separately.
-Maybe this should go into CodingStyle?
-
-------------------------------------------------------------------------
-From: Jeff Garzik <jgarzik at mandrakesoft dot com>
-
1) "unsigned int" is preferred to "int", it generates better asm code on
all platforms except sh5. This replacement needs to be done manually,
because often 'int' is required due to negative values -Exxx commonly
passed as error values.
-2) someone who knows DocBook, or is willing to learn, should go through
-and clean up Documentation/DocBook to kill all the warnings that occur
-during "make pdfdocs" and generally make the documents look nicer, and
-render smaller PDFs. See, not everyone needs to be a kernel hacker to
-really help out :)
-
------------------------------------------------------------------------
- when using sizeof consider using the variable and not the type, that way
if the type of the variable is changed we don't have to go seaching all
@@ -326,84 +331,6 @@
acme: yes, better clarify, if its a pointer you have to follow Jeff tip above
and use sizeof(*var)
------------------------------------------------------------------------------
-- uninitialize static variables initialized to 0, to make it go to the .bss,
- instead of .data
- __initdata has to be initialized, even if to 0 tough
-
------------------------------------------------------------------------------
-drivers/char/i8k.c duplicates arch/i386/kernel/dmi_scan.c
-Better would be to have dmi_scan.c set a flag which the i8k driver checks.
-
-------------------------------------------------------------------------
-Date: Fri, 21 Feb 2003 16:27:02 -0600
-From: Eric Bresie <ebresie at usa dot net>
-
-Check here: http://www.osdl.org/archive/cherry/stability/
-for additional kernel work.
-Also see here: http://www.osdl.org/projects/26lnxstblztn/results/
-
-------------------------------------------------------------------------
-From several people: clean up deprecated functions/interfaces:
-
-Convert users (callers) of deprecated functions (interfaces) to new
-interfaces:
-
-- call SET_MODULE_OWNER or use .owner = THIS_MODULE instead of using
- MOD_{INC,DEC}_USE_COUNT (only a few remain)
-
-- convert cli/sti/save_flags/save_flags_cli/restore_flags usage to
- accepted locking primitives;
- see Documentation/cli-sti-removal.txt and Documentation/spinlocks.txt
- for details, belows patch is an example:
- http://linux.bkbits.net:8080/linux-2.6/cset@419b78fcaLKtZt39OF_dslTbk-b3KQ?nav=index.html|ChangeSet@-8w
-
-------------------------------------------------------------------------
-From Linus:
-
-Check stack usage and reduce it in the worst cases.
-See: http://bugme.osdl.org/show_bug.cgi?id=386
-There is another script that checks function stack usage at
-http://kernelnewbies.org/scripts/ .
-
-------------------------------------------------------------------------
-For source files that don't have any license information in them,
-determine if they should be GPL or GPL/BSD etc. and add license information
-to them.
-
-------------------------------------------------------------------------
-From Eugene Teo:
-There are a handful of schedule() within spinlocks. That needs to
-be looked at. See the list on this page:
- http://kbugs.org/cgi-bin/index.py?page=bug_list&script=SpinSleepLazy&skernel=2.6.0-test11&sfile=
-
-Janitors should note that kbugs merely do a \*schedule\*, so there
-may be false alarms, not all are bugs.
-
-------------------------------------------------------------------------
-- pr_debug() from kernel.h could replace a lot of DPRINTK and similar macros.
-- same for pr_info()
-- min/max macros from kernel.h are safe, a lot of handcrafted MIN/MAX are not.
-- remove string concatenation with __FUNCTION__ (get rid of
- warnings, and get ready for __func__):
- -printk(KERN_INFO "blabla " __FUNCTION__ "\n");
- +printk(KERN_INFO "blabla %s\n", __FUNCTION__);
-
-------------------------------------------------------------------------
-From: Matthew Wilcox
-Subject: Calling yield() Considered Harmful
-
-[T: http://marc.theaimsgroup.com/?t=106554796200005]
-Don't forget to set_current_state(TASK_{,UN}INTERRUPTIBLE); before
-schedule*().
-Consider using msleep();.
-
-------------------------------------------------------------------------
-From: Eugene Teo
-
-- audit the return codes of kernel_thread(). Some sections of code
-use kernel_thread(), but failure of this function is not handled.
-
------------------------------------------------------------------------
From: Greg KH
@@ -417,54 +344,4 @@
- convert from pci_module_init to pci_register_driver
-
-------------------------------------------------------------------------
-From: Keith Owens, Andrew Morton
-
-Code in wrong sections:
-[http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=108640220401558]
-Run `make buildcheck` to find offending code
-
-----------------------------------------------------------------------
-From: Rusty Russell
-
-MODULE_PARM must die:
-+extern void __deprecated MODULE_PARM_(void);
-
-http://marc.theaimsgroup.com/?l=linux-kernel&m=109826168201622&w=2
-http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm2/broken-out/remove-module_parm-from-allyesconfig-almost.patch
-
-----------------------------------------------------------------------
-From: Jonathan Corbet
-
-Unified spinlock initialization:
-convert all explicit lock initializations to spin_lock_init() or
-rwlock_init(). (Besides consistency this also helps automatic lock
-validators and debugging code.)
-
-http://lwn.net/Articles/109505/
-http://linux.bkbits.net:8080/linux-2.6/cset@419a6f292wHnthuDzw7VfgECNLmvLg?nav=index.html|ChangeSet@-8w
-
-----------------------------------------------------------------------
-From: Matt Domsch
-Sat Jul 24 10:51:04 PDT 2004
-
-Add MODULE_VERSION() to modules.
-[http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=109068085714776]
-
-----------------------------------------------------------------------
-From: Andi Kleen
-Date: Sun, 19 Dec 2004 20:09:03 +0100
-
-Fix gcc 4 warnings.
-[http://marc.theaimsgroup.com/?t=110348353800003]
-
-----------------------------------------------------------------------
-From: Felipe W Damasio
-Date: Mon, 27 Dec 2004 15:37:08 -0200
-
-Felipe suggests auditing return codes in IDE drivers as it can cause
-a real problem.
-See original message for example patch:
-http://marc.theaimsgroup.com/?l=kernel-janitor-discuss&m=110416923101031
--------------------------------end-----------------------------------
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (43 preceding siblings ...)
2005-01-25 14:28 ` Domen Puncer
@ 2005-01-25 16:58 ` Randy.Dunlap
2005-01-25 17:11 ` Randy.Dunlap
` (5 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Randy.Dunlap @ 2005-01-25 16:58 UTC (permalink / raw)
To: kernel-janitors
Domen Puncer wrote:
>>
>>Second stage, that i'm doing now is to put stuff into sections (like it
>>is at the beginning of file).
>>I'm also thinking about ordering from easiest to hardest.
>
>
> I tried doing this, diff is ugly, lots of reordering, moving and
> making items from below shorter. Easiest to hardest ordering is very
> rough and subjective.
Rough and subjective are expected IMO, but also helpful to newcomers.
> I think i added all new suggestions.
> Deleted rcpci45.c and module licences entries.
>
> So... is it better, or should i just continue with previous version?
>
>
> $Id: TODO,v 1.25 2004/12/29 23:03:14 domen Exp $
> -==========-
>
> -None of the following items are in any order of importance or difficulty.
> -Where possible related items have been grouped together.
> +Send patches that add/fix items to kernel-janitors@lists.osdl.org.
> +Please don't add items to end of file.
>
>
> +Where it makes sense, sections are supposed to be ordered by incresing
> +difficulty.
> +
> +Links are marked with:
> +D: description/information about the issue
> +E: example patch
I like the shortened version (with D: and E:), although I expect that
some people would rather see the D: inline instead of having to
follow links. Also, it could easily be a little too sparse (or
spartan) for people who are new to Linux.
Crud, that doesn't help any, does it?
Did you get any other feedback on this?
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (44 preceding siblings ...)
2005-01-25 16:58 ` Randy.Dunlap
@ 2005-01-25 17:11 ` Randy.Dunlap
2005-01-25 17:52 ` Nish Aravamudan
` (4 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Randy.Dunlap @ 2005-01-25 17:11 UTC (permalink / raw)
To: kernel-janitors
Nish Aravamudan wrote:
> On Tue, 25 Jan 2005 08:58:27 -0800, Randy.Dunlap <rddunlap@osdl.org> wrote:
>
>>Domen Puncer wrote:
>>
>>>>Second stage, that i'm doing now is to put stuff into sections (like it
>>>>is at the beginning of file).
>>>>I'm also thinking about ordering from easiest to hardest.
>>>
>>>
>>>I tried doing this, diff is ugly, lots of reordering, moving and
>>>making items from below shorter. Easiest to hardest ordering is very
>>>rough and subjective.
>>
>>Rough and subjective are expected IMO, but also helpful to newcomers.
>>
>>
>>>I think i added all new suggestions.
>>>Deleted rcpci45.c and module licences entries.
>>>
>>>So... is it better, or should i just continue with previous version?
>>>
>>>
>>> $Id: TODO,v 1.25 2004/12/29 23:03:14 domen Exp $
>>> -==========-
>>>
>>>-None of the following items are in any order of importance or difficulty.
>>>-Where possible related items have been grouped together.
>>>+Send patches that add/fix items to kernel-janitors@lists.osdl.org.
>>>+Please don't add items to end of file.
>>>
>>>
>>>+Where it makes sense, sections are supposed to be ordered by incresing
>>>+difficulty.
>>>+
>>>+Links are marked with:
>>>+D: description/information about the issue
>>>+E: example patch
>>
>>I like the shortened version (with D: and E:), although I expect that
>>some people would rather see the D: inline instead of having to
>>follow links. Also, it could easily be a little too sparse (or
>>spartan) for people who are new to Linux.
>
>
> To account for this case, could we maintain two TODOs? They wouldn't
> be any different, just that one is less "spartan," as Randy said, than
> the other :) Basically inline the links there for now.... The
> sparse(r) TODO would be official & maintained; more verbose one would
> get updated whenever we got around to it. Link the latter from the
> former at the bottom, perhaps. So that you *have* to go through the
> sparse one :)
>
> I don't know if it's feasible (more work for KJ maintainer,
> admittedly), but might be a good compromise. Looks good otherwise,
> Domen.
If I were updating the TODO, I wouldn't care for that option.
Choose A xor B. :)
--
~Randy
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (45 preceding siblings ...)
2005-01-25 17:11 ` Randy.Dunlap
@ 2005-01-25 17:52 ` Nish Aravamudan
2005-01-25 18:08 ` Nish Aravamudan
` (3 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Nish Aravamudan @ 2005-01-25 17:52 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
On Tue, 25 Jan 2005 08:58:27 -0800, Randy.Dunlap <rddunlap@osdl.org> wrote:
> Domen Puncer wrote:
> >>
> >>Second stage, that i'm doing now is to put stuff into sections (like it
> >>is at the beginning of file).
> >>I'm also thinking about ordering from easiest to hardest.
> >
> >
> > I tried doing this, diff is ugly, lots of reordering, moving and
> > making items from below shorter. Easiest to hardest ordering is very
> > rough and subjective.
>
> Rough and subjective are expected IMO, but also helpful to newcomers.
>
> > I think i added all new suggestions.
> > Deleted rcpci45.c and module licences entries.
> >
> > So... is it better, or should i just continue with previous version?
> >
> >
> > $Id: TODO,v 1.25 2004/12/29 23:03:14 domen Exp $
> > -===================-
> >
> > -None of the following items are in any order of importance or difficulty.
> > -Where possible related items have been grouped together.
> > +Send patches that add/fix items to kernel-janitors@lists.osdl.org.
> > +Please don't add items to end of file.
> >
> >
> > +Where it makes sense, sections are supposed to be ordered by incresing
> > +difficulty.
> > +
> > +Links are marked with:
> > +D: description/information about the issue
> > +E: example patch
>
> I like the shortened version (with D: and E:), although I expect that
> some people would rather see the D: inline instead of having to
> follow links. Also, it could easily be a little too sparse (or
> spartan) for people who are new to Linux.
To account for this case, could we maintain two TODOs? They wouldn't
be any different, just that one is less "spartan," as Randy said, than
the other :) Basically inline the links there for now.... The
sparse(r) TODO would be official & maintained; more verbose one would
get updated whenever we got around to it. Link the latter from the
former at the bottom, perhaps. So that you *have* to go through the
sparse one :)
I don't know if it's feasible (more work for KJ maintainer,
admittedly), but might be a good compromise. Looks good otherwise,
Domen.
-Nish
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (46 preceding siblings ...)
2005-01-25 17:52 ` Nish Aravamudan
@ 2005-01-25 18:08 ` Nish Aravamudan
2005-01-25 18:54 ` Alexey Dobriyan
` (2 subsequent siblings)
50 siblings, 0 replies; 52+ messages in thread
From: Nish Aravamudan @ 2005-01-25 18:08 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 2663 bytes --]
On Tue, 25 Jan 2005 09:11:36 -0800, Randy.Dunlap <rddunlap@osdl.org> wrote:
> Nish Aravamudan wrote:
> > On Tue, 25 Jan 2005 08:58:27 -0800, Randy.Dunlap <rddunlap@osdl.org> wrote:
> >
> >>Domen Puncer wrote:
> >>
> >>>>Second stage, that i'm doing now is to put stuff into sections (like it
> >>>>is at the beginning of file).
> >>>>I'm also thinking about ordering from easiest to hardest.
> >>>
> >>>
> >>>I tried doing this, diff is ugly, lots of reordering, moving and
> >>>making items from below shorter. Easiest to hardest ordering is very
> >>>rough and subjective.
> >>
> >>Rough and subjective are expected IMO, but also helpful to newcomers.
> >>
> >>
> >>>I think i added all new suggestions.
> >>>Deleted rcpci45.c and module licences entries.
> >>>
> >>>So... is it better, or should i just continue with previous version?
> >>>
> >>>
> >>> $Id: TODO,v 1.25 2004/12/29 23:03:14 domen Exp $
> >>> -===================-
> >>>
> >>>-None of the following items are in any order of importance or difficulty.
> >>>-Where possible related items have been grouped together.
> >>>+Send patches that add/fix items to kernel-janitors@lists.osdl.org.
> >>>+Please don't add items to end of file.
> >>>
> >>>
> >>>+Where it makes sense, sections are supposed to be ordered by incresing
> >>>+difficulty.
> >>>+
> >>>+Links are marked with:
> >>>+D: description/information about the issue
> >>>+E: example patch
> >>
> >>I like the shortened version (with D: and E:), although I expect that
> >>some people would rather see the D: inline instead of having to
> >>follow links. Also, it could easily be a little too sparse (or
> >>spartan) for people who are new to Linux.
> >
> >
> > To account for this case, could we maintain two TODOs? They wouldn't
> > be any different, just that one is less "spartan," as Randy said, than
> > the other :) Basically inline the links there for now.... The
> > sparse(r) TODO would be official & maintained; more verbose one would
> > get updated whenever we got around to it. Link the latter from the
> > former at the bottom, perhaps. So that you *have* to go through the
> > sparse one :)
> >
> > I don't know if it's feasible (more work for KJ maintainer,
> > admittedly), but might be a good compromise. Looks good otherwise,
> > Domen.
>
> If I were updating the TODO, I wouldn't care for that option.
> Choose A xor B. :)
You are right, Randy. I am just concerned (like you, I think) that
newbies who wish to engage in Janitor work will get scared away by a
list that is far more terse than the current one. In the end, though,
I think the clean-up is much better in the long run, so go with it,
Domen.
-Nish
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (47 preceding siblings ...)
2005-01-25 18:08 ` Nish Aravamudan
@ 2005-01-25 18:54 ` Alexey Dobriyan
2005-01-26 8:34 ` walter harms
2005-02-22 12:15 ` Domen Puncer
50 siblings, 0 replies; 52+ messages in thread
From: Alexey Dobriyan @ 2005-01-25 18:54 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Tuesday 25 January 2005 16:28, Domen Puncer wrote:
> --- TODO-1.26
> +++ TODO-1.27
> +E: example patch
Really like this.
> +- get rid of verify_area with copy_*_user get/put_user
verify_area is semi-deprecated. At least nobody objected.
http://marc.theaimsgroup.com/?t=110506109900003&r=1&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=110557975201349&w=2
> +- printk() calls should include appropriate KERN_* constant
> http://linux.bkbits.net:8080/linux-2.5/patch@1.1555
Lets look at it more closely:
- if (i < 3)
- if (ZERO) printk ("%d: 0x%8.8x\n", i, leptr);
+ if (i < 3 && ZERO)
+ printk(KERN_DEBUG "%d: 0x%8.8x\n", i, leptr);
Technically leptr is int which is made from pointer through macro obfuscation.
And one shouldn't printk pointers in a non portable way. Quote from Al Viro:
One more thing: folks, please stop using crap like "%08x", (int)pointer.
It's not only non-portable (consider 64bit boxen), it's extra work for
no good reason. "%p" is standard and will do the right thing with less
PITA.
> +- fix warnings/errors
> + [D: http://developer.osdl.org/~cherry/compile/]
> + [D: http://www.osdl.org/projects/26lnxstblztn/results/]
> +- Fix gcc 4 warnings.
Also sparse warnings? Use -Wbitwise for _even more_ janitor work. :-)
Today somebody mentioned "make randconfig" on lkml. What about
$ make randconfig
Find out why it doesn't build. Don't forget to save .config. ?
I can add these three in a couple of days.
Alexey
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (48 preceding siblings ...)
2005-01-25 18:54 ` Alexey Dobriyan
@ 2005-01-26 8:34 ` walter harms
2005-02-22 12:15 ` Domen Puncer
50 siblings, 0 replies; 52+ messages in thread
From: walter harms @ 2005-01-26 8:34 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
Hi Alexey,
whats about something like "pedantic" or so ? the target would be to
make the kernel compile without warnings. you can add more tests every
level we clean. Also so to run programms that check for missing KERN_
what is already done to make sure noone introduces them again.
(perhaps a "pedandic=<level>" ?)
re,
walter
>
>
> Also sparse warnings? Use -Wbitwise for _even more_ janitor work. :-)
>
> Today somebody mentioned "make randconfig" on lkml. What about
>
> $ make randconfig
> Find out why it doesn't build. Don't forget to save .config. ?
>
> I can add these three in a couple of days.
>
> Alexey
>
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread* Re: [KJ] [RFC] TODO file cleanups
2005-01-17 23:11 [KJ] [RFC] TODO file cleanups Domen Puncer
` (49 preceding siblings ...)
2005-01-26 8:34 ` walter harms
@ 2005-02-22 12:15 ` Domen Puncer
50 siblings, 0 replies; 52+ messages in thread
From: Domen Puncer @ 2005-02-22 12:15 UTC (permalink / raw)
To: kernel-janitors
[-- Attachment #1: Type: text/plain, Size: 796 bytes --]
On 25/01/05 15:28 +0100, Domen Puncer wrote:
> On 18/01/05 00:11 +0100, Domen Puncer wrote:
> > Hi.
> >
> > Second stage, that i'm doing now is to put stuff into sections (like it
> > is at the beginning of file).
> > I'm also thinking about ordering from easiest to hardest.
>
> I tried doing this, diff is ugly, lots of reordering, moving and
> making items from below shorter. Easiest to hardest ordering is very
> rough and subjective.
> I think i added all new suggestions.
> Deleted rcpci45.c and module licences entries.
>
Finnaly, some update on this :-)
So... i went with the short version, it mostly reordered items,
descriptions are still there.
Also added recent Alexey's items.
For updates, preferably send patches that apply to:
http://janitor.kernelnewbies.org/TODO
Domen
[-- Attachment #2: Type: text/plain, Size: 167 bytes --]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply [flat|nested] 52+ messages in thread