Thanks for your guys' reply!
Peter, can you point me somewhere I can check the semantics of BKL? In
the past, I remembered BKL does block the kernel. So I am quite
confused now.
Also, I still don't understand why we use lock_kernel instead of some
finer granularity lock. Trond's answer gave me a feeling that this is
simply because the code is not carefully optimized. :)
-x
On 4/25/06, Peter Staubach <[email protected]> wrote:
> Xin Zhao wrote:
>
> >Thanks for your reply. So the only reason is for rpc auditing? If so,
> >why not just lock the code that updating the audit information? Now
> >the code is:
> >
> >lock_kernel()
> >rpc_execute()
> >unlock_kernel().
> >
> >That means the kernel will be blocked when rpc is executed, which
> >could take long time. Even if rpc_execute() won't take very long, this
> >implementation still looks inefficient. That's why I am a little
> >confused on this point.
> >
> >Any further thought?
> >
>
> I would suggest looking at the semantics of the BKL. They don't end up
> implying what you are suggesting. The kernel isn't really locked for
> the duration of the over the wire RPC.
>
> Thanx...
>
> ps
>
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
