Messages in this thread | | | Date | Wed, 30 Aug 2006 18:18:55 +0200 | From | Cedric Le Goater <> | Subject | Re: [PATCH] kthread: saa7134-tvaudio.c |
| |
Eric W. Biederman wrote:
[ ... ]
>>> That plus the obvious bit. For the pid namespace we have to declare >>> war on people storing a pid_t values. Either converting them to >>> struct pid * or removing them entirely. Doing the kernel_thread to >>> kthread conversion removes them entirely. >> we've started that war, won a few battles but some drivers need more work >> that a simple replace. If we could give some priorities, it would help to >> focus on the most important ones. check out the list bellow. > > Sure, I think I can help. > > There are a couple of test I can think of that should help. > 1) Is the pid value stored. If not a pid namespace won't affect > it's normal operation.
I've extracted this list from a table which includes a pid cache column. this pid cache column is not complete yet. I'd be nice if we could use a wiki to maintain this table, the existing openvz or vserver wiki ?
> 2) Is this thread started during kernel boot before this thread > could have a user space parent. If it can't have a user space > parent then it can't take a reference to user space resources.
ok we need to add this one.
> 3) Can the code be compiled modular and will it break when we stop > exporting kernel_thread.
got that also.
> 4) How frequently is this thing used. The more common code is probably > in better shape and more likely to get a good maintainer response, and > we care more :)
sure :) some drivers are for some exotic piece of hardware that are not currently found on a standard server.
> irqbalanced from arch/i386/kernel/io_apic.c should be safe to leave alone > because it doesn't store a pid_t, it is started during boot, and it can't > be compiled modular. > >>From what I have seen you can shorten the list by several entries by removing > code like irqbalanced that can't possibly cause us any problems. > kvoyagerd from arch/i386/mach-voyager/voyager_thread.c is another one.
ok thanks, will update.
> The first on my personal hit list is nfs. >> fs/lockd/clntlock.c >> fs/nfs/delegation.c >> net/sunrpc/svc.c > > Because it does store pid_t values, it isn't started during kernel boot, > it can be compiled modular, and people use it all of the time.
yes yes. hard stuff though which requires time.
> I do agree from what I have seen, that changing idioms to the kthread way of > doing things isn't simply a matter of substitute and replace which is > unfortunate. Although the biggest hurdle seems to be to teach kernel threads > to communicate with something besides signals. Which is a general help anyway. > > Unfortunately I'm distracted at the moment so I haven't gone through the entire > list but I hope this helps.
we would need a wiki to maintain the work in progress on that topic while we work on the pidspace.
another list to maintain would be the pid_t to struct pid replacement.
C. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |