August 2002 - Darwin-kernel

Re: lseek in a KEXT
by Jim Magee 08 Aug '02

08 Aug '02

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(a)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.

1 0

Kernel Panic at register_sockfilter() call
by Davinder P Singh 08 Aug '02

08 Aug '02

Hi Folks, Few days ago I started working on NKEs and now I am stuck at the very first step. I started with the tutorial code VMSIfy.c provided by Apple in developer documentation and I am unable to register my NKE using register_sockfilter() kernel panic occurs at this function call. I tried with a most simple NFDescriptor structure such as this one but with no success and only panic: *********************************************************************** /* Dispatch vectors when VMSIfy has pulled out */ struct sockif VIsockif_null; struct sockutil VIsockutil_null; #define VMSIFY_HANDLE 0xfacefeed struct NFDescriptor VMSIfy ={ {NULL, NULL}, {NULL, NULL}, VMSIFY_HANDLE, NFD_GLOBAL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL }; kern_return_t test_start (kmod_info_t * ki, void * d) { int retval; struct protosw *pp; /* Find the protosw we want to sidle up to */ pp = pffindproto(AF_INET, IPPROTO_TCP, SOCK_STREAM); if ( pp == NULL ) return(EPFNOSUPPORT); VMSIfy.nf_soif = &VIsockif_null; VMSIfy.nf_soutil = &VIsockutil_null; /* Register the filter */ retval = register_sockfilter(&VMSIfy, NULL, pp, NFF_AFTER); return KERN_SUCCESS; } *********************************************************************** Please excuse my naiveti if I am doing anything silly and help me get out of this. Also in the tutorial one header file is included named #include <mach/kernel_extension.h> But there is no such file on the system. I am using Mac OS 10.1. Any reasons for this please? Thanks and Regards, Davinder Pal Singh. TCS. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Mac OS X - VM Working Set
by Eugenio Jarosiewicz 07 Aug '02

07 Aug '02

On Wednesday, August 7, 2002, at 02:26 PM, Brian Bergstrand wrote: Lunedl, Agosto 5, 2002, alle 03:59 PM, Jim Magee ha scritto: On Saturday, July 27, 2002, at 05:43 PM, luisella wrote: Hello, I'm studying Darwin kernel and I found some information about working set on Mach Virtual Memory. "The first time that an application is launched in a given user context, the initial working set required to start the application is captured and stored in a file..... /var/vm/app_profile". Why I didn't find this file into my iMac with OS X 10.1.5? In Mac OS X 10.1.x (Darwin 5), the VM system would dynamically track working sets of running applications and use that for page replacement/fetch purposes. But the cache of early working set info across launches is new to Mac OS X 10.2 (Darwin 6). --Jim Is this really in Darwin 6? I have 6C115 and I don't see any files in /var/vm other than swap files. Are the profiles kept in a different directory? Take a look @ xnu/bsd/vm/vm_unix.c and search for the path. -ej _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Mac OS X - VM Working Set
by Brian Bergstrand 07 Aug '02

07 Aug '02

Lunedl, Agosto 5, 2002, alle 03:59 PM, Jim Magee ha scritto: On Saturday, July 27, 2002, at 05:43 PM, luisella wrote: Hello, I'm studying Darwin kernel and I found some information about working set on Mach Virtual Memory. "The first time that an application is launched in a given user context, the initial working set required to start the application is captured and stored in a file..... /var/vm/app_profile". Why I didn't find this file into my iMac with OS X 10.1.5? In Mac OS X 10.1.x (Darwin 5), the VM system would dynamically track working sets of running applications and use that for page replacement/fetch purposes. But the cache of early working set info across launches is new to Mac OS X 10.2 (Darwin 6). --Jim Is this really in Darwin 6? I have 6C115 and I don't see any files in /var/vm other than swap files. Are the profiles kept in a different directory? Brian Bergstrand <http://www.classicalguitar.net/brian/> PGP Key ID: 0xB6C7B6A2 One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say. - Will Durant _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: Mac OS X - VM Working Set
by luisella 07 Aug '02

07 Aug '02

Thank you for your kind reply. I looking for Working-set "window" (range, delta). How much frames does working set algorithm considers? What is the name of variable into source code? thanks, /\AndreA/\ Lunedl, Agosto 5, 2002, alle 03:59 PM, Jim Magee ha scritto: On Saturday, July 27, 2002, at 05:43 PM, luisella wrote: Hello, I'm studying Darwin kernel and I found some information about working set on Mach Virtual Memory. "The first time that an application is launched in a given user context, the initial working set required to start the application is captured and stored in a file..... /var/vm/app_profile". Why I didn't find this file into my iMac with OS X 10.1.5? In Mac OS X 10.1.x (Darwin 5), the VM system would dynamically track working sets of running applications and use that for page replacement/fetch purposes. But the cache of early working set info across launches is new to Mac OS X 10.2 (Darwin 6). --Jim _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: lseek in a KEXT
by Justin C. Walker 07 Aug '02

07 Aug '02

On Wednesday, August 7, 2002, at 10:51 AM, David Blanton wrote: So, I guess I will do some in-line assem to build a call to lseek and then bl to 000aeaac (lseek) ... what do you think? See my previous reply. Regards, Justin -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-Large \ / Ribbon Campaign X Help cure HTML Email / \ _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: lseek in a KEXT
by Justin C. Walker 07 Aug '02

07 Aug '02

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 | darwin-kernel(a)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.

1 0

Re: lseek in a KEXT
by David Blanton 07 Aug '02

07 Aug '02

So, I guess I will do some in-line assem to build a call to lseek and then bl to 000aeaac (lseek) ... what do you think? David Blanton Elisar Software Corporation Albuquerque _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Communication problem between a NKE and a User-land with one built in 10.1 and the other on 10.2?
by Stéphane Sudre 07 Aug '02

07 Aug '02

I'm having a communication problem between a NKE which has been built in 10.1 and a User-land application which I'm building in 10.2. The 10.2 user-land application does not seem to be able to connect and chat via a socket NKE to the NKE (I'm using the 10.1 NKEMgr header). The 10.1 user-land application is able to connect and have an interesting chat with the NKE via a socket NKE both on 10.1 and 10.2. The issue is that I'm making some tests and to do these tests I need to build the Userland application on Jaguar (to avoid some Framework linking I'm going to get if I build it in 10.1). Does this issue mean that there's been a change to the communication header/process/whatever with NKE socket in 10.2 and that there can be an incompatibility? _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0

Re: lseek in a KEXT
by David Blanton 07 Aug '02

07 Aug '02

JCW ... This is just info for you ........... I did kmodload -v -o /tmp/sym macos/kext gdb add-symbol-file /tmp/sym gdb info func and behold 000aeaa4 delete 000aeaac lseek 000aec04 olseek 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 On Wednesday, August 7, 2002, at 11:09 AM, Justin C. Walker wrote: On Wednesday, August 7, 2002, at 10:02 AM, David Blanton wrote: if lseek is libc and not available why is the symbol for lseek in the kext symbol file? I dunno. Do you call 'lseek()' in your extension? Is the symbol defined or undefined? I have no idea how you got the kext symbol file, or how you built the extension, so it's pretty difficult to answer your question. You can, of course, execute 'ld' with a reference to your extension and libc, and get something which may appear to be successfully linked. The result will blow up in your face, once you light the fuse, of course. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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. David Blanton Elisar Software Corporation Albuquerque _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)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.

1 0