January 2007 - Darwin-kernel

Re: User-space to kernel communication
by Greg 10 Jan '07

10 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 9, 2007, at 8:32 PM, Michael Smith wrote: typedef struct { unsigned char buffer[256]; unsigned char bufferSize; } MyIOUserClientArg; Again, thank you for all your help so far, I really appreciate it. - Greg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Also, as I asked in the other email, can you pass a pointer to a user-land allocated buffer as a parameter to a method call for the kernel to use? You can, although the kernel can't access it directly. As I pointed out previously, if the data is small (you mentioned 50 bytes, which is very small) you're better off just copying it. If you need to pass it to hardware, or to map it, you need to construct an IOMemoryDescriptor referencing it. By "just copying it" do you mean, as Brian pointed out, passing a structure of this sort: Or do you mean that the kernel has read-access to user-allocated memory (so that you could copy the data pointed to by a pointer). This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Michael Smith 10 Jan '07

10 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 9, 2007, at 2:23 PM, Michael Smith wrote: No. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Jan 9, 2007, at 11:47 AM, Greg wrote: Personally, I would implement a UserClient with two methods; one that blocks waiting for a message from the kernel, the other that ships data in. This avoids blowing a kernel thread on the communication portal (making it easier to have multiple clients) by requiring both threads to be owned by the user process. This does sound like a viable idea. It would still require me to have two threads on the user-land side though (calling these methods), would that be a problem? Also, as I asked in the other email, can you pass a pointer to a user-land allocated buffer as a parameter to a method call for the kernel to use? You can, although the kernel can't access it directly. As I pointed out previously, if the data is small (you mentioned 50 bytes, which is very small) you're better off just copying it. If you need to pass it to hardware, or to map it, you need to construct an IOMemoryDescriptor referencing it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Greg 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 9, 2007, at 2:23 PM, Michael Smith wrote: - Greg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Personally, I would implement a UserClient with two methods; one that blocks waiting for a message from the kernel, the other that ships data in. This avoids blowing a kernel thread on the communication portal (making it easier to have multiple clients) by requiring both threads to be owned by the user process. This does sound like a viable idea. It would still require me to have two threads on the user-land side though (calling these methods), would that be a problem? Also, as I asked in the other email, can you pass a pointer to a user-land allocated buffer as a parameter to a method call for the kernel to use? You don't mention whether the kernel->userspace direction produces arbitrary quantities of data, but using a KC socket you're going to be tempted to ignore the issue of kernel-side buffering/flow control, and may be in for a nasty surprise when the socket buffer fills up and your attempt to enqueue data either blocks or fails. I don't think that should be a problem, there will only be one user- land application talking to the kext and I can implement checks for that. This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Michael Smith 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 9, 2007, at 11:10 AM, Greg wrote: It has its drawbacks. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Both the kernel and the user-space app will each have at least two threads (using the pthreads interface, which the kernel seems to support) in them for communication with each other. Each thread in the kernel will be responsible for communicating with its corresponding thread in the user-space app over kernel control sockets (so one socket is for user->kernel communication, and the other for the reverse). This way I can supply the kext with data and listen for notifications at the same time. By using one communication method for supplying data and doing notifications I hope to simplify everything and make it easier to maintain, perhaps as just a simple C-based kext. Does this sound OK? Again, thank you all for your advice! Personally, I would implement a UserClient with two methods; one that blocks waiting for a message from the kernel, the other that ships data in. This avoids blowing a kernel thread on the communication portal (making it easier to have multiple clients) by requiring both threads to be owned by the user process. You don't mention whether the kernel->userspace direction produces arbitrary quantities of data, but using a KC socket you're going to be tempted to ignore the issue of kernel-side buffering/flow control, and may be in for a nasty surprise when the socket buffer fills up and your attempt to enqueue data either blocks or fails. You also haven't talked about what your kext is actually doing, so again it's hard to know which mechanisms would fit most closely. This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Greg 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 9, 2007, at 11:32 AM, Quinn wrote: The considerations I usually apply are: <http://developer.apple.com/samplecode/KauthORama/index.html> Does this sound OK? Again, thank you all for your advice! - Greg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Wow, thank you all for your replies, they have been very illuminating. I'm not sure what the proper protocol is for replying to multiple people but instead of sending several emails I think I'll try to make a gestalt out of them (I've always wanted to use that word!). On Jan 9, 2007, at 11:17 AM, Kevin Elliott wrote: You haven't mentioned a lot of detail about what your doing (how fast the data needs to be moved, how often, etc.), but setProperty is also an option for passing data into the kernel. It's by far the easiest to implement and if you don't need high performance and you aren't moving lots of data it's a reasonable option. You're right I should have given more information. I need to be able to send data from the user-space program to the kext and it needs to store this data in memory (cumulatively). The transfer rate of data into the kernel will likely be minimal on resources, so speed is not an issue there, however communication in the other direction might be more intensive. I need the kernel to asynchronously tell the user- space program when certain events happen in a notification-type scheme. So for this I will have to somehow manage multiple threads most likely. Also, I'm not writing a hardware driver so I'm not bound to using the IOKit which is why I'm kind of overwhelmed with all of these implementation possibilities (methods for sending data... methods for communication... etc) 2. You can pack the data into a buffer and pass that in via one of the "IOConnectMethod*StructureI*" methods. In this case, you just pass in a pointer to a buffer and its length. Again, this can vary from request to request. Are you saying that I could allocate a buffer in user-space and pass a pointer to that buffer to the kernel? I thought that there were memory zone restrictions on this type of stuff. This would be very convenient if it was true as I could simply copy that data out of the buffer to store it in my kext. o If you're already knee deep in BSD KPI, there's a general preference for BSD-based mechanism (sysctl or sockets). o If you're already knee deep in I/O Kit, there's a general preference for IOUserClient. o sysctl is /very/ simple. o sysctl has a command line tool you can use for basic testing. That's very convenient. For example, look at my KauthORama sample. o sysctl has no notification mechanism. If the client needs to wake up when the value changes, sysctl is inappropriate. Both sockets and IOUserClient let you notify a user process when things change. o If you need low latency or high bandwidth, IOUserClient is probably your best bet. It has low latency because it's based on Mach messaging (this is especially true prior to 10.4, where BSD stuff can get stuck behind the kernel funnel). It supports high bandwidth because you can pass large blocks out of band (that is, by memory mapping). Yes actually I've been going through your KauthORama example, thank you for writing it! I'm currently just exploring my options so I'm not knee deep in anything yet (other than various PDFs :-p). So far it seems that the kern control stuff is what I'm looking for as it seems like I would be able to just use it for anything I could possible want (except extremely low latency, high bandwidth stuff), including notifications. Here is my idea for how my app will work, I would greatly appreciate any input on it! Both the kernel and the user-space app will each have at least two threads (using the pthreads interface, which the kernel seems to support) in them for communication with each other. Each thread in the kernel will be responsible for communicating with its corresponding thread in the user-space app over kernel control sockets (so one socket is for user->kernel communication, and the other for the reverse). This way I can supply the kext with data and listen for notifications at the same time. By using one communication method for supplying data and doing notifications I hope to simplify everything and make it easier to maintain, perhaps as just a simple C-based kext. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Understanding cores...
by Derek Kumar 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 8, 2007, at 4:05 PM, Michael Tuexen wrote: Derek _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Well on that system the NKE is load always, because it is required by the application running on that Mac Pro. In the meantime another system was setup (on a different hardware) the it also crashes a lot. BTW: A lot means a couple of times per day. And yes, the cores we get (using a core dump server), are all like this (some pointed to bugs in the NKE in the past, but these could be fixed, then also SCTP.kext was explicitly mentioned in the paniclog). Any idea how to narrow down the problem? If the EIP values in the "paniclog" register dump are identical/ similar across all the crashes you've observed (note that "unresolved kernel trap" is just a generic label), and only occur when your driver is loaded, it's likely to be memory corruption as I noted previously. Is it always an EBP based access (typically a local or parameter) in idle_thread() that's causing the fault? The loop in idle_thread() briefly enables interrupts and disables them, so if you have an interrupt filter routine (that executes at interrupt context) that could be another point where corruption could occur (in addition to the the saved context at the base of the thread's kernel stack I mentioned previously--corruption of the register context below the interrupt stack frame that contains the saved value of the EBP register, for instance). Unfortunately, there's no single magic bullet when it comes to identifying sources of memory corruption of this type--determining the patterns and location of corruption and binary search via logging/ tracing is one approach (after carefully walking through your code to look for erroneous stores to memory, bad DMA bounds, stack overflows etc.; I don't think page protection/debug register type schemes to trap the bad store (assuming it's not a physical mode store) would be useful here since the register context would be very frequently accessed. Logic analyzers (very expensive) would be a last resort). The kernel trace facility (/usr/local/bin/trace -h) can tell you what events (such as interrupts and context switches) occurred on that processor, but given that it panics, you'd probably have to examine the trace buffer in memory (see xnu/bsd/kern/kdebug.c in the kernel sources for the internals of the trace facility) to extract the last few trace events. This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Michael Smith 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 8, 2007, at 4:18 PM, Greg wrote: = Mike - Greg On Jan 8, 2007, at 7:07 PM, Brian Bergstrand wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 8, 2007, at 5:41 PM, Greg wrote: - Greg On Jan 8, 2007, at 6:17 PM, Greg Miller wrote: G~ - Greg On Jan 8, 2007, at 3:15 PM, Josh Graessley wrote: Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFotzdedHYW7bHtqIRAmI5AKDCYEhYQLuutfXymWbA2TNMJt114wCg81qa 4bWZYkEPhRifL2tebI39JTQ= =qi/Q -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/drivers%40mu.org _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… >From what I've read about IOUserClient and its IOConnectMethod*'s, it does not seem like they support passing variable length data. Perhaps I'm missing something, could you point me to what you're referring to or perhaps a code example? If you have an upper bound on your data, and it is around 4KiB or so, then it makes no sense to implement a "variable length" interface of any sort. The work you do supporting that interface will be comparable to, if not greater, than the work involved in copying those 4KiB in/out on your call, especially if you are not making this call at a rate of thousands per second. There is no "correct" way. There are ways that make more "sense" given your current setup, but that's about it. If you want bi- directional communication and you are already an IOKit kext, the easiest method will be an IOUserClient nub (as Josh already stated). You could also easily use a kernel control socket or memory mapping (from personal experience, the former is a tad easier than the latter because of certain kernel restrictions on mapping memory from userland into the kernel). Also from personal experience, sysctls and ioctls do not make for easy bi-directional communication channels. Sorry for the followup, but perhaps somebody could just advice me on a specific method. That document does provide details for the sysctl API but skims over memory-mapping and a few others. Apple provides an IODataQueue example but that is only for kernel -> user-client communication, I'm not exactly sure how I would reverse that direction. However, it seems that sysctl is a viable option for my purposes. It does seem to be able to handle variable length data of moderate size, I guess I'll just use that. The reason for my confusion is simply the shear number of options and the rather sparse documentation on them; I'm just trying to find the "correct" way of doing this... Take a look at the document at http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/boundaries/chapter_14_section_1.html#// apple_ref/doc/uid/TP30000905-CH217-DontLinkElementID_9 On 1/8/07, Greg <greg(a)kinostudios.com> wrote: Like I said, I'm trying to send the kernel variable length data of around 50 bytes. I am using the IOKit but I would also like to know how to do this without it. Is there any documentation on this? I would really prefer to avoid blindly going through header files. > > This depends on what you are trying to communicate with in the > kernel. If you are already using IOKit, I would imagine an > IOUserClient would be the way to go. If you're writing a non- IOKit > kext, you may want to look in to a kernel control socket (sys/ > kern_control.h). > > -josh > > On Jan 7, 2007, at 6:40 PM, Greg wrote: > >> Hi, what is the best way(s) to send variable length data (around >> 50 bytes or so) to a kernel extension from a user-land >> application? Are there different ways to do this if the kext uses >> the IOUserClient schema to talk to user-land apps? If you could >> also point me to documentation or a tutorial on how to do this I >> would be much obliged! >> >> Thanks, >> This email sent to drivers(a)mu.org This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Andrew Gallatin 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Quinn writes: > o On current systems, there is no (supported :-) way to create an > IOUserClient that supports 64-bit user space programs. If you need > to support such programs, IOUserClient isn't for you. FWIW, tradidtional BSD ioctls work just fine for communication with a 64-bit user space program (I'm talking about you calling cdevsw_add() and managing things yourself, as opposed to using an IOKit class). As a bonus, ioctls were faster (ie, lower latency) than the user client stuff as well when I measured them on ppc sometime in the late 10.3 timeframe. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Dan Markarian 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hey Greg, IOUserClient does support variable length data. You can find documentation on IOUserClient at: Dan On 8 Jan 2007, at 9:19 PM, Greg wrote: - Greg On Jan 8, 2007, at 8:04 PM, Brian Bergstrand wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 8, 2007, at 6:18 PM, Greg wrote: typedef struct { unsigned char buffer[256]; unsigned char bufferSize; } MyIOUserClientArg; Then just cast 'buffer' as needed. The interesting bits as far as kernel<->user communication are in: pplib/ppmsg.h pplib/pplib.c kern/PeerProtector.c kern/pp_session.c kern/pplog.c - Greg On Jan 8, 2007, at 7:07 PM, Brian Bergstrand wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 8, 2007, at 5:41 PM, Greg wrote: - Greg On Jan 8, 2007, at 6:17 PM, Greg Miller wrote: G~ - Greg On Jan 8, 2007, at 3:15 PM, Josh Graessley wrote: Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFouoOedHYW7bHtqIRAmtZAJ4hLO5Ip3DX8dAVZHxlyd5chFcxmQCfQX7p g3XhL63bYRraNiZPGHU4csw= =Z7ob -----END PGP SIGNATURE----- _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… http://lists.apple.com/archives/darwin-development/2001/May/ msg00760.html http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ WritingDeviceDriver/MakingHWAccessible/chapter_5_section_2.html http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ WritingDeviceDriver/MakingHWAccessible/chapter_5_section_3.html http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ WritingDeviceDriver/MakingHWAccessible/chapter_5_section_4.html It seems that the easiest means to communicate to your I/O Kit driver, for your purposes, is to send a CFData property to it with IORegistryEntrySetCFProperties() in user space, which is automatically routed to your IOService::setProperties() method in your driver in the kernel. See the "Accessing Device Properties" section for further documentation. Thanks for pointing this out! I've looked into this some more and found documentation on kernel control sockets here: http://developer.apple.com/documentation/Darwin/Conceptual/ NKEConceptual/index.html?http://developer.apple.com/documentation/ Darwin/Conceptual/NKEConceptual/control/chapter_3_section_2.html This looks very interesting and so far it seems to be exactly what I want as it uses a familiar API (bsd sockets) and allows for bidirectional communication. With this available I don't see why anyone would want to use sysctl or the IOUserClient stuff... are there any disadvantages associated with using kernel control sockets over the aforementioned sysctl/IOConnectMethod stuff? >From what I've read about IOUserClient and its IOConnectMethod*'s, it does not seem like they support passing variable length data. Perhaps I'm missing something, could you point me to what you're referring to or perhaps a code example? No, you'd have to combine memory mapping with an IOUserKitClient to get true variable length support (by passing a ptr in a struct arg to your method). However, you say you only need around 50 bytes, so just have a static buffer in your struct large enough to fix the max amount of data: As for an example, that's about all I can give you for IOUserClient, but I do have a public project that uses a kernel control socket to send variable sized data if you are interested in seeing that: http://prdownloads.sourceforge.net/peerguardian/ PeerGuardianSrc_1.4.2.zip?download There is no "correct" way. There are ways that make more "sense" given your current setup, but that's about it. If you want bi- directional communication and you are already an IOKit kext, the easiest method will be an IOUserClient nub (as Josh already stated). You could also easily use a kernel control socket or memory mapping (from personal experience, the former is a tad easier than the latter because of certain kernel restrictions on mapping memory from userland into the kernel). Also from personal experience, sysctls and ioctls do not make for easy bi-directional communication channels. Sorry for the followup, but perhaps somebody could just advice me on a specific method. That document does provide details for the sysctl API but skims over memory-mapping and a few others. Apple provides an IODataQueue example but that is only for kernel -> user-client communication, I'm not exactly sure how I would reverse that direction. However, it seems that sysctl is a viable option for my purposes. It does seem to be able to handle variable length data of moderate size, I guess I'll just use that. The reason for my confusion is simply the shear number of options and the rather sparse documentation on them; I'm just trying to find the "correct" way of doing this... Take a look at the document at http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/boundaries/chapter_14_section_1.html#// apple_ref/doc/uid/TP30000905-CH217-DontLinkElementID_9 On 1/8/07, Greg <greg(a)kinostudios.com> wrote: Like I said, I'm trying to send the kernel variable length data of around 50 bytes. I am using the IOKit but I would also like to know how to do this without it. Is there any documentation on this? I would really prefer to avoid blindly going through header files. > > This depends on what you are trying to communicate with in the > kernel. If you are already using IOKit, I would imagine an > IOUserClient would be the way to go. If you're writing a non-IOKit > kext, you may want to look in to a kernel control socket (sys/ > kern_control.h). > > -josh > > On Jan 7, 2007, at 6:40 PM, Greg wrote: > >> Hi, what is the best way(s) to send variable length data (around >> 50 bytes or so) to a kernel extension from a user-land >> application? Are there different ways to do this if the kext uses >> the IOUserClient schema to talk to user-land apps? If you could >> also point me to documentation or a tutorial on how to do this I >> would be much obliged! >> >> Thanks, >> _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/markarian% 40apple.com This email sent to markarian(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Quinn 09 Jan '07

09 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Actually, you can do this in two ways with a custom IOUserClient: The considerations I usually apply are: o sysctl is /very/ simple. <http://developer.apple.com/samplecode/KauthORama/index.html> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 19:04 -0600 8/1/07, Brian Bergstrand wrote: On Jan 8, 2007, at 6:18 PM, Greg wrote: >From what I've read about IOUserClient and its IOConnectMethod*'s, it does not seem like they support passing variable length data. No, you'd have to combine memory mapping with an IOUserKitClient to get true variable length support (by passing a ptr in a struct arg to your method). 1. You can break the data into a sequence of words, and pass it in using IOConnectMethodScalarIScalarO. For example, on input, the first parameter is a count of the number of words supplied in the varargs list. Most folks typically use a fixed value for any given method index, but there's no requirement to do so. 2. You can pack the data into a buffer and pass that in via one of the "IOConnectMethod*StructureI*" methods. In this case, you just pass in a pointer to a buffer and its length. Again, this can vary from request to request. At 21:19 -0500 8/1/07, Greg wrote: With this available I don't see why anyone would want to use sysctl or the IOUserClient stuff... are there any disadvantages associated with using kernel control sockets over the aforementioned sysctl/IOConnectMethod stuff? o If you're already knee deep in BSD KPI, there's a general preference for BSD-based mechanism (sysctl or sockets). o If you're already knee deep in I/O Kit, there's a general preference for IOUserClient. o sysctl has a command line tool you can use for basic testing. That's very convenient. For example, look at my KauthORama sample. o sysctl has no notification mechanism. If the client needs to wake up when the value changes, sysctl is inappropriate. Both sockets and IOUserClient let you notify a user process when things change. o If you need low latency or high bandwidth, IOUserClient is probably your best bet. It has low latency because it's based on Mach messaging (this is especially true prior to 10.4, where BSD stuff can get stuck behind the kernel funnel). It supports high bandwidth because you can pass large blocks out of band (that is, by memory mapping). o IOUserClient allows you to create shared mappings. You can use this either for high bandwidth communication, or to share state between you user and kernel code. o On current systems, there is no (supported :-) way to create an IOUserClient that supports 64-bit user space programs. If you need to support such programs, IOUserClient isn't for you. This email sent to site_archiver(a)lists.apple.com

1 0