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 <[email protected]>
---------------------------
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
Who: Dominik Brodowski <[email protected]>
---------------------------
What: ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue)
When: December 2005
Who: Harald Welte <[email protected]>
---------------------------
What: remove EXPORT_SYMBOL(kernel_thread)
When: August 2006
Who: Christoph Hellwig <[email protected]>
---------------------------
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 <[email protected]>
---------------------------
What: i2c-ite and i2c-algo-ite drivers
When: September 2006
Who: Jean Delvare <[email protected]>
---------------------------
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
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 <[email protected]>
>
> ---------------------------
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
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 <[email protected]>
There are a lot of modular users left. It'll go away as soon as these
users have disappeared.
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 <[email protected]>
>
> 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);
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 <[email protected]>
> >
> > 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
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
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 <[email protected]>
>> 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
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 <><
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;
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
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
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
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
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
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 <[email protected]>
to the patch.