feature-removal-schedule obsoletes

feature-removal-schedule obsoletes

[Jiri Slaby]

Hello,

I figured out these requests for removal with past dates. What's the state of
them now, could you reschedule or delete (or just confirm here to post one patch
correcting this file)?

[Why:s were removed in this mail]

---------------------------

What:   RAW driver (CONFIG_RAW_DRIVER)
When:   December 2005
Who:    Adrian Bunk <bunk@stusta.de>

---------------------------

What:   PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When:   November 2005
Who:    Dominik Brodowski <linux@brodo.de>

---------------------------

What:   ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue)
When:   December 2005
Who:    Harald Welte <laforge@netfilter.org>

---------------------------

What:   remove EXPORT_SYMBOL(kernel_thread)
When:   August 2006
Who:    Christoph Hellwig <hch@lst.de>

---------------------------

What:   CONFIG_FORCED_INLINING
When:   June 2006
Who:    Arjan van de Ven

---------------------------

What:   Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
        (temporary transition config option provided until then)
        The transition config option will also be removed at the same time.
When:   before 2.6.19
Who:    Arjan van de Ven <arjan@linux.intel.com>

---------------------------

What:   i2c-ite and i2c-algo-ite drivers
When:   September 2006
Who:    Jean Delvare <khali@linux-fr.org>

---------------------------

thanks,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: feature-removal-schedule obsoletes

[Jean Delvare]

Hi Jiri,

On Sun, 15 Oct 2006 16:31:29 +0159, Jiri Slaby wrote:
> I figured out these requests for removal with past dates. What's the state of
> them now, could you reschedule or delete (or just confirm here to post one patch
> correcting this file)?
> 
> [Why:s were removed in this mail]
> (...)
> ---------------------------
> 
> What:   i2c-ite and i2c-algo-ite drivers
> When:   September 2006
> Who:    Jean Delvare <khali@linux-fr.org>
> 
> ---------------------------

The patch is ready, it's in my local stack:
http://khali.linux-fr.org/devel/linux-2.6/i2c-delete-ite-bus-driver.patch

I'll push it upstream soon.

Thanks,
-- 
Jean Delvare

Re: feature-removal-schedule obsoletes

[Christoph Hellwig]

On Sun, Oct 15, 2006 at 04:31:29PM +0159, Jiri Slaby wrote:
> What:   remove EXPORT_SYMBOL(kernel_thread)
> When:   August 2006
> Who:    Christoph Hellwig <hch@lst.de>

There are a lot of modular users left.  It'll go away as soon as these
users have disappeared.

Re: feature-removal-schedule obsoletes

[Arnd Bergmann]

On Monday 16 October 2006 15:33, Christoph Hellwig wrote:
> On Sun, Oct 15, 2006 at 04:31:29PM +0159, Jiri Slaby wrote:
> > What:   remove EXPORT_SYMBOL(kernel_thread)
> > When:   August 2006
> > Who:    Christoph Hellwig <hch@lst.de>
>
> There are a lot of modular users left.  It'll go away as soon as these
> users have disappeared.

It seems that most of the users that are left are for pretty obscure
functionality, so I wouldn't expect that to happen so soon. Maybe we
should mark it as __deprecated in the declaration?

	Arnd <><

./arch/arm/kernel/ecard.c:      ret = kernel_thread(ecard_task, NULL, CLONE_KERNEL);
./arch/arm/kernel/process.c:pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags)
./arch/i386/kernel/io_apic.c:   if (kernel_thread(balanced_irq, NULL, CLONE_KERNEL) >= 0)
./arch/i386/mach-voyager/voyager_thread.c:      if(kernel_thread(thread, NULL, CLONE_KERNEL) < 0) {
./arch/ia64/sn/kernel/xpc_main.c:       pid = kernel_thread(xpc_activating, (void *) ((u64) partid), 0);
./drivers/macintosh/adb.c:      adb_probe_task_pid = kernel_thread(adb_probe_task, NULL, SIGCHLD | CLONE_KERNEL);
./drivers/macintosh/mediabay.c:         kernel_thread(media_bay_task, NULL, CLONE_KERNEL);
./drivers/macintosh/therm_pm72.c:       ctrl_task = kernel_thread(main_control_loop, NULL, SIGCHLD | CLONE_KERNEL);
./drivers/macintosh/therm_windtunnel.c:                 x.poll_task = kernel_thread( control_loop, NULL, SIGCHLD | CLONE_KERNEL );
./drivers/media/dvb/dvb-core/dvb_ca_en50221.c:  ret = kernel_thread(dvb_ca_en50221_thread, ca, 0);
./drivers/media/dvb/dvb-core/dvb_frontend.c:    ret = kernel_thread (dvb_frontend_thread, fe, 0);
./drivers/media/dvb/ttpci/av7110.c:     ret = kernel_thread(arm_thread, (void *) av7110, 0);
./drivers/media/video/saa7134/saa7134-tvaudio.c:                dev->thread.pid = kernel_thread(my_thread,dev,0);
./drivers/media/video/msp3400-driver.c:                 v4l_warn(client, "kernel_thread() failed\n");
./drivers/mmc/mmc_queue.c:      ret = kernel_thread(mmc_queue_thread, mq, CLONE_KERNEL);
./drivers/mtd/mtd_blkdevs.c:    ret = kernel_thread(mtd_blktrans_thread, tr, CLONE_KERNEL);
./drivers/pci/hotplug/cpci_hotplug_core.c:              pid = kernel_thread(event_thread, NULL, 0);
./drivers/pci/hotplug/cpci_hotplug_core.c:              pid = kernel_thread(poll_thread, NULL, 0);
./drivers/pci/hotplug/cpqphp_ctrl.c:    pid = kernel_thread(event_thread, NULL, 0);
./drivers/pci/hotplug/ibmphp_hpc.c:     tid_poll = kernel_thread (hpc_poll_thread, NULL, 0);
./drivers/pci/hotplug/pciehp_ctrl.c:    pid = kernel_thread(event_thread, NULL, 0);
./drivers/pnp/pnpbios/core.c:   if (kernel_thread(pnp_dock_thread, NULL, CLONE_KERNEL) > 0)
./drivers/s390/net/lcs.c:               kernel_thread(lcs_recovery, (void *) card, SIGCHLD);
./drivers/s390/net/qeth_main.c:         kernel_thread(qeth_register_ip_addresses, (void *)card,SIGCHLD);
./drivers/s390/scsi/zfcp_erp.c: retval = kernel_thread(zfcp_erp_thread, adapter, SIGCHLD);
./drivers/scsi/libsas/sas_scsi_host.c:  res = kernel_thread(sas_queue_thread, sas_ha, 0);
./drivers/usb/atm/usbatm.c:     int ret = kernel_thread(usbatm_do_heavy_init, instance, CLONE_KERNEL);
./drivers/usb/atm/usbatm.c:             usb_err(instance, "%s: failed to create kernel_thread (%d)!\n", __func__, ret);
./fs/afs/cmservice.c:           ret = kernel_thread(kafscmd, NULL, 0);
./fs/afs/kafsasyncd.c:  ret = kernel_thread(kafsasyncd, NULL, 0);
./fs/afs/kafstimod.c:   ret = kernel_thread(kafstimod, NULL, 0);
./fs/cifs/connect.c:                    rc = (int)kernel_thread((void *)(void *)cifs_demultiplex_thread, srvTcp,
./fs/jffs/inode-v23.c:  c->thread_pid = kernel_thread (jffs_garbage_collect_thread,
./fs/jffs2/background.c:        pid = kernel_thread(jffs2_garbage_collect_thread, c, CLONE_FS|CLONE_FILES);
./fs/lockd/clntlock.c:          if (kernel_thread(reclaimer, host, CLONE_KERNEL) < 0)
./fs/nfs/delegation.c:  status = kernel_thread(recall_thread, &data, CLONE_KERNEL);
./net/bluetooth/bnep/core.c:    err = kernel_thread(bnep_session, s, CLONE_KERNEL);
./net/bluetooth/cmtp/core.c:    err = kernel_thread(cmtp_session, session, CLONE_KERNEL);
./net/bluetooth/hidp/core.c:    err = kernel_thread(hidp_session, session, CLONE_KERNEL);
./net/bluetooth/rfcomm/core.c:  kernel_thread(rfcomm_run, NULL, CLONE_KERNEL);
./net/core/pktgen.c:    err = kernel_thread((void *)pktgen_thread_worker, (void *)t,
./net/core/pktgen.c:            printk("pktgen: kernel_thread() failed for cpu %d\n", t->cpu);
./net/ipv4/ipvs/ip_vs_sync.c:   if ((pid = kernel_thread(sync_thread, startup, 0)) < 0) {
./net/ipv4/ipvs/ip_vs_sync.c:   if ((pid = kernel_thread(fork_sync_thread, &startup, 0)) < 0) {
./net/rxrpc/krxiod.c:   return kernel_thread(rxrpc_krxiod, NULL, 0);
./net/rxrpc/krxsecd.c:  return kernel_thread(rxrpc_krxsecd, NULL, 0);
./net/rxrpc/krxtimod.c: ret = kernel_thread(krxtimod, NULL, 0);
./net/sunrpc/svc.c:     error = kernel_thread((int (*)(void *)) func, rqstp, 0);

Re: feature-removal-schedule obsoletes

[Adrian Bunk]

On Tue, Oct 24, 2006 at 09:24:49PM +0200, Arnd Bergmann wrote:
> On Monday 16 October 2006 15:33, Christoph Hellwig wrote:
> > On Sun, Oct 15, 2006 at 04:31:29PM +0159, Jiri Slaby wrote:
> > > What:   remove EXPORT_SYMBOL(kernel_thread)
> > > When:   August 2006
> > > Who:    Christoph Hellwig <hch@lst.de>
> >
> > There are a lot of modular users left.  It'll go away as soon as these
> > users have disappeared.
> 
> It seems that most of the users that are left are for pretty obscure
> functionality, so I wouldn't expect that to happen so soon. Maybe we
> should mark it as __deprecated in the declaration?

__deprecated_for_modules (__deprecated would imply it would be 
completely removed).

> 	Arnd <><

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

Re: feature-removal-schedule obsoletes

[Jörn Engel]

On Tue, 24 October 2006 21:24:49 +0200, Arnd Bergmann wrote:
>
> ./drivers/mtd/mtd_blkdevs.c:    ret = kernel_thread(mtd_blktrans_thread, tr, CLONE_KERNEL);

This one should be ripped out.  I did it as part of a bugfix for a
customer kernel not too long ago.

Jörn

-- 
Joern's library part 3:
http://inst.eecs.berkeley.edu/~cs152/fa05/handouts/clark-test.pdf

Re: feature-removal-schedule obsoletes

[Pierre Ossman]

Arnd Bergmann wrote:
> On Monday 16 October 2006 15:33, Christoph Hellwig wrote:
>> On Sun, Oct 15, 2006 at 04:31:29PM +0159, Jiri Slaby wrote:
>>> What:   remove EXPORT_SYMBOL(kernel_thread)
>>> When:   August 2006
>>> Who:    Christoph Hellwig <hch@lst.de>
>> There are a lot of modular users left.  It'll go away as soon as these
>> users have disappeared.
> 
> It seems that most of the users that are left are for pretty obscure
> functionality, so I wouldn't expect that to happen so soon. Maybe we
> should mark it as __deprecated in the declaration?
> 

What should be used to replace it? The MMC block driver uses it to
manage the block device queue. I am not that intimate with the block
layer so I do not know the proper fix.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: feature-removal-schedule obsoletes

[Arnd Bergmann]

On Saturday 28 October 2006 10:34, Pierre Ossman wrote:
> 
> What should be used to replace it? The MMC block driver uses it to
> manage the block device queue. I am not that intimate with the block
> layer so I do not know the proper fix.
> 
You should use kthread_create().

	Arnd <><

Re: feature-removal-schedule obsoletes

[Christoph Hellwig]

On Sat, Oct 28, 2006 at 10:34:51AM +0200, Pierre Ossman wrote:
> > It seems that most of the users that are left are for pretty obscure
> > functionality, so I wouldn't expect that to happen so soon. Maybe we
> > should mark it as __deprecated in the declaration?
> > 
> 
> What should be used to replace it? The MMC block driver uses it to
> manage the block device queue. I am not that intimate with the block
> layer so I do not know the proper fix.

kthread_create/kthread_run.  Here's a draft patch (and it's against
a rather old tree and untested due to lack of hardware so it really
should be considered just a draft).


Index: linux-2.6/drivers/mmc/mmc_queue.c
===================================================================
--- linux-2.6.orig/drivers/mmc/mmc_queue.c	2006-10-28 12:48:42.000000000 +0200
+++ linux-2.6/drivers/mmc/mmc_queue.c	2006-10-28 12:57:12.000000000 +0200
@@ -10,12 +10,12 @@
  */
 #include <linux/module.h>
 #include <linux/blkdev.h>
+#include <linux/kthread.h>
 
 #include <linux/mmc/card.h>
 #include <linux/mmc/host.h>
 #include "mmc_queue.h"
 
-#define MMC_QUEUE_EXIT		(1 << 0)
 #define MMC_QUEUE_SUSPENDED	(1 << 1)
 
 /*
@@ -59,7 +59,6 @@
 {
 	struct mmc_queue *mq = d;
 	struct request_queue *q = mq->queue;
-	DECLARE_WAITQUEUE(wait, current);
 
 	/*
 	 * Set iothread to ensure that we aren't put to sleep by
@@ -67,12 +66,7 @@
 	 */
 	current->flags |= PF_MEMALLOC|PF_NOFREEZE;
 
-	daemonize("mmcqd");
-
-	complete(&mq->thread_complete);
-
 	down(&mq->thread_sem);
-	add_wait_queue(&mq->thread_wq, &wait);
 	do {
 		struct request *req = NULL;
 
@@ -84,7 +78,7 @@
 		spin_unlock_irq(q->queue_lock);
 
 		if (!req) {
-			if (mq->flags & MMC_QUEUE_EXIT)
+			if (kthread_should_stop())
 				break;
 			up(&mq->thread_sem);
 			schedule();
@@ -95,10 +89,8 @@
 
 		mq->issue_fn(mq, req);
 	} while (1);
-	remove_wait_queue(&mq->thread_wq, &wait);
 	up(&mq->thread_sem);
 
-	complete_and_exit(&mq->thread_complete, 0);
 	return 0;
 }
 
@@ -113,7 +105,7 @@
 	struct mmc_queue *mq = q->queuedata;
 
 	if (!mq->req)
-		wake_up(&mq->thread_wq);
+		wake_up_process(mq->thread);
 }
 
 /**
@@ -152,36 +144,31 @@
 			 GFP_KERNEL);
 	if (!mq->sg) {
 		ret = -ENOMEM;
-		goto cleanup;
+		goto cleanup_queue;
 	}
 
-	init_completion(&mq->thread_complete);
-	init_waitqueue_head(&mq->thread_wq);
 	init_MUTEX(&mq->thread_sem);
 
-	ret = kernel_thread(mmc_queue_thread, mq, CLONE_KERNEL);
-	if (ret >= 0) {
-		wait_for_completion(&mq->thread_complete);
-		init_completion(&mq->thread_complete);
-		ret = 0;
-		goto out;
+	mq->thread = kthread_run(mmc_queue_thread, mq, "mmcqd");
+	if (IS_ERR(mq->thread)) {
+		ret = PTR_ERR(mq->thread);
+		goto free_sg;
 	}
 
- cleanup:
+	return 0;
+
+ free_sg:
 	kfree(mq->sg);
 	mq->sg = NULL;
-
+ cleanup_queue:
 	blk_cleanup_queue(mq->queue);
- out:
 	return ret;
 }
 EXPORT_SYMBOL(mmc_init_queue);
 
 void mmc_cleanup_queue(struct mmc_queue *mq)
 {
-	mq->flags |= MMC_QUEUE_EXIT;
-	wake_up(&mq->thread_wq);
-	wait_for_completion(&mq->thread_complete);
+	kthread_stop(mq->thread);
 
 	kfree(mq->sg);
 	mq->sg = NULL;
Index: linux-2.6/drivers/mmc/mmc_queue.h
===================================================================
--- linux-2.6.orig/drivers/mmc/mmc_queue.h	2006-10-28 12:49:31.000000000 +0200
+++ linux-2.6/drivers/mmc/mmc_queue.h	2006-10-28 12:54:54.000000000 +0200
@@ -6,8 +6,7 @@
 
 struct mmc_queue {
 	struct mmc_card		*card;
-	struct completion	thread_complete;
-	wait_queue_head_t	thread_wq;
+	struct task_struct	*thread;
 	struct semaphore	thread_sem;
 	unsigned int		flags;
 	struct request		*req;

Re: feature-removal-schedule obsoletes

[Jörn Engel]

On Sat, 28 October 2006 10:34:51 +0200, Pierre Ossman wrote:
> 
> What should be used to replace it? The MMC block driver uses it to
> manage the block device queue. I am not that intimate with the block
> layer so I do not know the proper fix.

Why does the MMC block driver use a thread?  Is there a technical
reason for this or could it be done in original process context as
well, removing some code and useless cpu scheduler overhead?

Jörn

-- 
When people work hard for you for a pat on the back, you've got
to give them that pat.
-- Robert Heinlein

Re: feature-removal-schedule obsoletes

[Russell King]

On Tue, Oct 31, 2006 at 04:57:56PM +0100, J?rn Engel wrote:
> On Sat, 28 October 2006 10:34:51 +0200, Pierre Ossman wrote:
> > 
> > What should be used to replace it? The MMC block driver uses it to
> > manage the block device queue. I am not that intimate with the block
> > layer so I do not know the proper fix.
> 
> Why does the MMC block driver use a thread?  Is there a technical
> reason for this or could it be done in original process context as
> well, removing some code and useless cpu scheduler overhead?

As I understand it, there is no guarantee that a block drivers request
function will be called in process context - it could be called in
interrupt context.

The MMC subsystem needs process context to issue commands since the
process of issuing commands entails various sleeps.  Hence why the
MMC block has its own process context.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: feature-removal-schedule obsoletes

[Pierre Ossman]

Jörn Engel wrote:
> Why does the MMC block driver use a thread?  Is there a technical
> reason for this or could it be done in original process context as
> well, removing some code and useless cpu scheduler overhead?
>   

I'm afraid I don't know the block layer very well, but that thread seems
to be polling the block layer for requests and handing the over to the
routines in mmc_block.c.

How do you set it up so that the block layer itself calls the necessary
function?

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: feature-removal-schedule obsoletes

[Jörn Engel]

On Tue, 31 October 2006 19:32:12 +0000, Russell King wrote:
> On Tue, Oct 31, 2006 at 04:57:56PM +0100, J?rn Engel wrote:
> > 
> > Why does the MMC block driver use a thread?  Is there a technical
> > reason for this or could it be done in original process context as
> > well, removing some code and useless cpu scheduler overhead?
> 
> As I understand it, there is no guarantee that a block drivers request
> function will be called in process context - it could be called in
> interrupt context.

Makes some sense.  I would still like to understand when a request
function is called from interrupt context, but if it is, the thread is
certainly necessary.

Jörn

-- 
This above all: to thine own self be true.
-- Shakespeare

Re: feature-removal-schedule obsoletes

[Pierre Ossman]

Christoph Hellwig wrote:
> On Sat, Oct 28, 2006 at 10:34:51AM +0200, Pierre Ossman wrote:
>   
>> What should be used to replace it? The MMC block driver uses it to
>> manage the block device queue. I am not that intimate with the block
>> layer so I do not know the proper fix.
>>     
>
> kthread_create/kthread_run.  Here's a draft patch (and it's against
> a rather old tree and untested due to lack of hardware so it really
> should be considered just a draft).
>
>   

Patch looks ok to me and seems to work fine. Are you willing to sign off
on it?

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: feature-removal-schedule obsoletes

[Christoph Hellwig]

On Mon, Nov 13, 2006 at 04:15:27PM +0100, Pierre Ossman wrote:
> Christoph Hellwig wrote:
> > On Sat, Oct 28, 2006 at 10:34:51AM +0200, Pierre Ossman wrote:
> >   
> >> What should be used to replace it? The MMC block driver uses it to
> >> manage the block device queue. I am not that intimate with the block
> >> layer so I do not know the proper fix.
> >>     
> >
> > kthread_create/kthread_run.  Here's a draft patch (and it's against
> > a rather old tree and untested due to lack of hardware so it really
> > should be considered just a draft).
> >
> >   
> 
> Patch looks ok to me and seems to work fine. Are you willing to sign off
> on it?

Sure, please add a

Signed-off-by: Christoph Hellwig <hch@lst.de>

to the patch.