Re: lseek in a KEXT
Re: lseek in a KEXT
- Subject: Re: lseek in a KEXT
- From: "Justin C. Walker" <email@hidden>
- Date: Wed, 7 Aug 2002 10:56:41 -0700
On Wednesday, August 7, 2002, at 10:36 AM, David Blanton wrote:
JCW ... This is just info for you ...........
Thanks. This explains what is happening:
I did kmodload -v -o /tmp/sym macos/kext
gdb add-symbol-file /tmp/sym
gdb info func
This gives you a list of *all* symbols in the kernel + loaded
extensions, although it doesn't mention where the symbols are defined.
and behold
000aeaa4 delete
000aeaac lseek
000aec04 olseek
As it happens, and you noticed, these symbols are in the kernel.
'lseek' in this case is the *implementation* of the lseek system call;
not the lseek system call itself. To simplify life for those who work
down here, system call implementations are often named the same as the
system call itself. This can cause confusion for the hapless novice, of
course.
with no reference to lseek in the kext at all
so, i though great I will define the function in my kext and call it
since the symbol is there
and that did not work as I got
kmodload: kld(): kmodload: Undefined symbols:kmodload:
kmodload: _lseek__Fixi
This, I'll guess, is the result of your calling 'lseek()' in your
extension (which I'll also guess is an IOKit gizmo) without mentioning
that it (lseek) is C, not C++ (which you might assume is covered in a
header file somewhere; but that's a separate issue [that putative header
file should not be included in a kernel module]).
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?
Regards,
Justin
--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics | When LuteFisk is outlawed
| Only outlaws will have
| LuteFisk
*--------------------------------------*-------------------------------*
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.