>> The answer is yes. IPC and py-pf are examples. If you don't
>> think of packet filtering as kernel coding, I can understand.
>> But clearly the Python interfaces to fork(), waitpid(),
>> signal(), alarm() and so forth are forays into the once
>> private garden of C.
The routines listed above aren't in the kernel. They're in
libc just like routines such as printf, memcpy, etc. The above
libc routines do make system calls into the kernel to perform
the desired functions, but those routines are not in the
kernel, and calling them is certainly not "kernel coding".
Yes, Python provides specific wrappers for many C library
functions.
Yes, the ctypes module provides a generic method for calling
foreign library functions.
No, using those wrappers is not what anybody I know would call
"kernel coding".
> Being able to call routines in the kernel is *not* the same as
> kernel coding.
As far as I know, Python doesn't provide the user with the
ability to make system calls into the kernel. Even if it did,
that isn't really "kernel coding" either. It's just making
system calls.
> Calling C routines is *not* the same as kernel coding.
> Actually writing the routines that are to be called, and that
> constitute the kernel itself, *is* kernel coding. And as
> wonderful as Python is, it is *not* for kernel coding.
>
> Having just looked at Py-PF, it is *managing* the firewall,
> not implementing it. Again, not kernel coding.
Didn't somebody once demonstrate how to put a VM into kernel
space so that you could write kernel code in Python? Maybe it
was just a discussion about how it could be done in theory.
There have been a few JVM-in-hardware projects, so I suppose
you could use Jython to write kernel code for those machines.
--
Grant Edwards grante Yow! I have accepted
at Provolone into my life!
visi.com
--
http://mail.python.org/mailman/listinfo/python-list
