On Wed, 2014-11-26 at 07:50 +0800, Ian Kent wrote: > > > > If we are going to set this stuff up in the kernel we need a reference > > process that we can create children of because what is possible with > > respect to containers keeps changing, and it is extremely error prone to > > figure out what all othe crazy little bits are, and to update everything > > every time someone tweaks the kernel's capabilities. We have kthreadd > > because it was too error prone to scrub a userspace thread of all of the > > userspace bits and make it the equivalent of what kthreadd is today. > > > > Of course it is also rather nice to have something to hang everything > > else on. > > > > In summary we need a reference struct task that is all setup properly > > so that we can create an appropriate kernel thread. > > I'm having trouble understanding what your getting at here but I'm not > that sharp so bear with me. > > When call_usermodehelper() is called it's called from a process that is > within the context within which the execution is required.
Umm .. OK, that's probably not quite right either .... For nfsd I think it's OK but for nfs clients the context is probably that of the caller .... Whereas the helper to get a key info maybe does need to be called in the context of the caller ..... > > So what information do we not have available for setup? > > Are you saying that the problem is that when the user mode helper run > thread is invoked we don't have the information available that was > present when call_usermodehelper() was called and that's where the > challenge lies? > > Ian > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
