Putting stuff in the kernel is very dangerous; it's only done
if there's absolutely no other way. Since DCOM is just
a library for doing TCP/IP RPC, kinda, the only reason to put
it in the kernel would be speed. (That's why RPC code is in
the kernel; the NFS kernel modules need it, and they really
do require maximal speed.)
Somebody *has* put something very similar to DCOM into the
kernel already; see http://korbit.sourceforge.net/
However, that was mostly done as an intellectual exercise;
nobody seriously uses it, and it's not in the main kernel.
Your basic assumption -- that putting DCOM in the kernel is
the best way to make sure it's available to everyone -- is
mistaken. After all, the program '/bin/ls' is available to
everyone, and it's not in the kernel. To make DCOM available
to everyone, just implement it as a good user-level library,
and people will pick it up as they need it.
If you want to help, there is a project implementing DCOM on Linux
at http://freedce.sourceforge.net/
Improving that project is the way to go; later, if performance
concerns merit it, you could consider doing whacky things
like moving it into the kernel.
Or you might consider convincing The Open Group to release
their DCOM on Unix compliance test suite as open source.
They'll do it for the right price, I'm pretty sure.
- Dan
-
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/