Hello, On 4/20/07, Cedric Le Goater <clg@fr.ibm.com> wrote:But all kernel threads are supposed to be only *in-kernel* implementation details. Isn't a userspace tool whose behaviour relies on the existence (or even the knowledge of the existence) of any kernel thread *broken by design*? Yes, so although userspace shouldn't be bothering with kernel threads in the first place, that does not mean that such tools do not exist. So we'll have to live with this (unfortunate) naming for some time, till we can get rid of it later. Which is similar to the habit of some kernel threads in there that actually *do* want to export the knowledge of their existence (and even a signals-based interface!) to userspace. Eric did receive some nacks on his patches that tried to remove the signals business from kernel threads on this account, but perhaps that too is something that we could get rid of later (hopefully by that time those using signals in kernel threads would have realized their folly and shifted to something else :-) Satyam -
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Andrew Morton | -mm merge plans for 2.6.23 |
| KAMEZAWA Hiroyuki | Re: 2.6.23-mm1 |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
git: | |
| Alan Cox | Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
