On Wednesday, August 7, 2002, at 01:56 PM, Justin C. Walker wrote: If you check the archives for this and the -developers lists, you'll see numerous threads dealing with the subject of making BSD "system calls" or libc calls from the kernel or extensions. The answer's always the same: it's A Bad Thing (TM). Don't do it: - the calling sequences aren't the same, even though the procedure names are (or may be) - the setup for calling a system call can be quite involved, and is an implementation detail subject to change - the assumptions internal to the system call implementation may not support calling from within the kernel's address space - other libc calls may make assumptions about run-time environment that are not valid when in kernel mode (and they may themselves make real system calls, which would cause breakage). When you do this, you leave yourself open for all sorts of breakage, either in the field when someone uses the system in a way you haven't tested; or at the next release, when Apple re-implements everything from the ground up, in a non-compatible way. Did I mention you should not do this? I'll add to Justin's comments. DON'T DO THIS! File I/O from within the kernel is not for the faint of heart, and you certainly cannot use the same read/write/lseek, etc... APIs from within the kernel that you use outside (as Justin said, those symbols are there, but they are the implementation routine for the system call that ASSUMES a user-level client). All the APIs that are valid to call from within the kernel (usually the vnode ops) already have the offset resolved into a parameter. Tracking an offset pointer in a file handle is a user<-->kernel boundary crossing issue only. --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.