Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library

[Steve French <smfrench@austin.rr.com>]

Arjan van de Ven wrote:

>>You are taking the wrong approach.
>>
>>The _only_ question that matters is:
>>Why is it technically impossible to do the same in userspace?
>>
>>If it's technically possible to do the same in userspace, it must not be 
>>done in the kernel.
>>    
>>
>
>
>that is not a reasonable statement because...
>1) you can do all of tcp/ip in userspace just fine
>2) you can do the NFS server in userspace
>3) ...
>4) ...
>
>there are reasons why things that can be done in userspace sometimes
>still make sense to do in kernel space, performance could be one of
>those reasons, being unreasonably complex in userspace is another.
>
>Identity management to some degree belongs in the kernel, simply because
>identity *enforcing* is in the kernel. Some things related to security
>need to be in the kernel at least partially just to avoid a LOT of hairy
>issues and never ending series of security holes due to the exceptional
>complexity you get.
>
>
>  
>
Yes - nicely stated.  There are a few cases in which code would be 
simpler in kernel, and there are even more cases where performance or 
security considerations argue for a mostly kernel implementation of a 
key piece of function.  Although I don't know if the case has been 
reproven for web servers (userspace) or nfs server (kernel) recently,  
this case may be easier to work through if we understood the likely use 
scenarios better of this piece of code. I don't know the right answer 
for the particular math library question, but I have not seen the 
typical argument considered about whether a user space implementation of 
this paticular function could deadlock - ie would this code (proposed to 
move to userspace) ever be called in a path in which the:
    1) kernel were out of memory and userspace is needed to resolve the 
write out of dirty memory
    2) hang due to code going up to userspace in path in which key 
kernel semaphores must be held across the call.