June 2009 - Darwin-kernel - lists.apple.com

Re: Kalloc and lck_mtx_lock
by Quinn 24 Jun '09

24 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com <http://developer.apple.com/SampleCode/MFSLives/listing2.html> <http://developer.apple.com/SampleCode/MFSLives/listing1.html> Yes. 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 23:13 -0400 23/6/09, Greg wrote: Hmm.. my apologies, I am admittedly a little bit deficient in my understandings of the internals of the kernel, but I'm not sure as to what you mean by this: as you really don't have a good way of knowing whether your service will ultimately be depended on by code that has to run to free memory in order for the allocation to succeed. OK, let's consider a concrete example. It's very common for folks asking this question to be building KEXTs that run on the page fault path. In that case allocating memory while holding a mutex can easily deadlock the system. Your allocation blocks waiting for memory. The pager blocks waiting for your service. Deadlock. This obvious affects any KEXTs associated with the disk (VFS plug-ins and I/O Storage Family stuff), but it can also affect network KEXTs as well (because we support paging over the network). That doesn't leave a lot of KEXTs that are safe from this one specific edge case. And there are many more edge cases out there (-: Unfortunately it would be extremely difficult (perhaps impossible), and totally out of line with KISS, for me to avoid allocating while holding a lock. The kernel is not really a KISS-compliant environment. Sometimes you have to jump through hoops to achieve correctness. If you have any doubt about this, check out the HNode layer I created for VFS plug-ins. This design pattern is very common in kernel code: do lots of work, then discover that you need memory, so abandon all that work, drop all your locks, allocate the memory, and then redo all of that work. There tends to be lots of gotos in kernel code (-: One other question if I may, is it then better to call one of the malloc functions (while holding a lock) in non-blocking way (i.e. OSMalloc_noblock), or does it not matter? Notwithstanding our general recommendation not to do this, non-blocking is definitely better than blocking. And if it does matter (and OSMalloc_noblock/kalloc_noblock is better), then should I take much greater caution to check for it returning NULL than if I were to use plain old OSMalloc? Which raises an interesting point. If you can handle the allocator returning NULL, why not just write the code correctly in the first place? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kalloc and lck_mtx_lock
by Greg 24 Jun '09

24 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Best, - Greg On Jun 23, 2009, at 10:53 PM, Michael Smith wrote: On Jun 23, 2009, at 6:27 PM, Greg wrote: Greg, I know I'm going to regret this. 8) = 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.… Hmm.. my apologies, I am admittedly a little bit deficient in my understandings of the internals of the kernel, but I'm not sure as to what you mean by this: as you really don't have a good way of knowing whether your service will ultimately be depended on by code that has to run to free memory in order for the allocation to succeed. Unfortunately it would be extremely difficult (perhaps impossible), and totally out of line with KISS, for me to avoid allocating while holding a lock. One other question if I may, is it then better to call one of the malloc functions (while holding a lock) in non-blocking way (i.e. OSMalloc_noblock), or does it not matter? And if it does matter (and OSMalloc_noblock/kalloc_noblock is better), then should I take much greater caution to check for it returning NULL than if I were to use plain old OSMalloc? I've read in Amit Singh's OS X Internals book that it's not safe to call OSMalloc/kalloc while holding a "simple lock", are lck_mtx_t's therefore safe to hold when calling one of these functions? If not, then is there any way of doing so? Perhaps by using a different kind of lock or different kind of alloc function? It's generally a bad idea to call an allocation function while holding arbitrary locks, particularly if you are implementing a service, as you really don't have a good way of knowing whether your service will ultimately be depended on by code that has to run to free memory in order for the allocation to succeed. It's also very difficult to test and debug these cases, so for the most part I would encourage you simply to avoid allocating while holding any sort of lock, period. That being said, there is nothing intrinsic about mutex locks that makes it not safe to call the allocator whilst you hold one. -- Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile -- Hippocrates This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kalloc and lck_mtx_lock
by Michael Smith 24 Jun '09

24 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ 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

Kalloc and lck_mtx_lock
by Greg 24 Jun '09

24 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thanks, - 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.… I've read in Amit Singh's OS X Internals book that it's not safe to call OSMalloc/kalloc while holding a "simple lock", are lck_mtx_t's therefore safe to hold when calling one of these functions? If not, then is there any way of doing so? Perhaps by using a different kind of lock or different kind of alloc function? This email sent to site_archiver(a)lists.apple.com

1 0

Re: io_connect_get_notification_semaphore and x86_64
by Duane Murphy 24 Jun '09

24 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 In a previous version, I used the async methods (setAsyncResult and sendAsyncReference). I didn't like the client side because it required too much integration with the app (e.g. RunLoops). I assume for compatibility, I would use the newer "64" versions. Do those work for both 32 and 64-bit applications? I'm not sure which notifications you are referring too. On Jun 23, 2009, at 5:18 PM, Alexei Kosut wrote: > Duane, > > What are you using the notification semaphore for? Perhaps you can > find a replacement with one of the supported IOKit user client > functions, e.g., asynchronous methods or notifications. > > Alexei > > On Jun 23, 2009, at 2:22 PM, Duane Murphy wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> (moving to darwin-kernel in the hopes that someone here might be able >> to help.) >> >> I now know how this works, but it is unclear why this is not being >> supported for 64-bit kernels. It would be nice if someone at Apple >> could comment, otherwise, it's going to cost me a DTS incident and a >> lot of work. :-( >> >> io_connect_get_notification_semaphore() is mig generated. The >> semaphore_t type has special mig handlers for incoming translation, >> outgoing translation and destruction. The opaque semaphore_t >> structure >> contains the mach port. The data sent to user space is the mach port >> with send rights. >> >> As this requires access to the opaque parts of the semaphore_t >> structure, it is not a supported interface. >> >> It sure would be nice if this was supported or something like it. >> >> ...Duane >> >> On Jun 23, 2009, at 11:13 AM, Duane Murphy wrote: >> >>> * PGP Signed: 06/23/09 at 11:13:32 >>> >>> I've done some more work on this and could use some recommendations >>> on how to make this work. >>> >>> My first attempt was to simply pass the semaphore_t from the kernel >>> back to the app. That didn't work at all. >>> >>> I went back to the 32-bit app and the old code and noticed that the >>> semaphore_t in user space does not appear to be the semaphore_t from >>> the kernel. There must be some massaging going on somewhere. >>> >>> What kind of massaging is happening so that I can get this to work. >>> >>> Thanks for the help, >>> >>> On Jun 19, 2009, at 12:27 PM, Duane Murphy wrote: >>> >>>>> Old Signed: 06/19/09 at 12:27:20 >>>> >>>> Is there a replacement or recommendation for a replacement for >>>> io_connect_get_notification_semaphore() for 64-bit clients to an >>>> IOUserClient? >>>> >>>> We were using io_connect_get_notification_semaphore() in our 32-bit >>>> client side interface to our kext. It makes sense that this doesn't >>>> work in LP64 (semphore* would be a problem). >>>> >>>> Is there a recommended method for doing this ourselves? Is there a >>>> new and exciting interface wired to >>>> IOUserClient::getNotificationSemaphore()? >>> >>> ...Duane >>> >>> >>> >>> >>> * Duane Murphy <duanemurphy(a)mac.com> >>> * 0x10E2BD82(L) >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/darwin-dev/duanemurphy >>> %40mac.com >>> >>> This email sent to duanemurphy(a)mac.com >> >> ...Duane >> >> >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: PGP Desktop 9.10.0 (Build 500) >> Charset: US-ASCII >> >> wsBVAwUBSkFJ9Erg9acQ4r2CAQicHwf/Z8Qf8B8h1VsjdDsa7o9SZr8L5+leyHmw >> 2hIxU1KpNqh45a2K8+TlrQBJvavfc9br2PTDwshg4IK3JKprTVh1h+6omDsjeL2E >> /s+7Rj6kHUQzZOG0lMyGNyUk7MPY9LKeP+MKqoSuF6UcI2fLWnFkDSzXzevQm+AM >> MU+kkn/RQbwuRwt99tWxI/sfwwY0HCTPMtagVSQ7CF9wCzWhsw2KQYH4Qd1Kse6i >> 7EiUMV+6g2UksKsanQG80vfonVby0asjM+ea5i2iY4r0SErxkPfe4dhOb71B67/F >> 142FDpxW9ytHLIcddn8MIEMIFS6cHN1dFbFP/4DhN65Mg0LziPYIMA== >> =8wJE >> -----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/akosut%40apple.com >> >> This email sent to akosut(a)apple.com > ...Duane -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) Charset: US-ASCII wsBVAwUBSkF5Bkrg9acQ4r2CAQjfyAf/aSIjvWYukUXqmdNwQSFFJwlsIqYehiHx DA8FtUw/Nqo8Vx1v6CEKRY6bQawvKaxcwKsHeWVvIRzXbEB3xrUBC91VWh7xL8OL Sq59qH9StigPp3VmPXdvpUxcwPkp36pSCZBTB3M99Ddq8R9jgex2e+UcV32kEQ0+ EUlZEtchLEbNg4fHNtNiyobK0NGFsWdKxQx/1IgtTAWh3g06z9zFw1YpWa1VQzOe jMwB8WBMF/8+8Ia3OqJ3b0HT6vKkFxE9cWkZzyTWW/4XvU7oHJlHXwRYNTdE+wNK LReovCPIvNhiY6vFqGNw1DrVT2huUIDDSrQvg7W1oL4Q+a5DB2qIAw== =zilv -----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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: io_connect_get_notification_semaphore and x86_64
by Alexei Kosut 24 Jun '09

24 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Duane, Alexei On Jun 23, 2009, at 2:22 PM, Duane Murphy wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 (moving to darwin-kernel in the hopes that someone here might be able to help.) I now know how this works, but it is unclear why this is not being supported for 64-bit kernels. It would be nice if someone at Apple could comment, otherwise, it's going to cost me a DTS incident and a lot of work. :-( io_connect_get_notification_semaphore() is mig generated. The semaphore_t type has special mig handlers for incoming translation, outgoing translation and destruction. The opaque semaphore_t structure contains the mach port. The data sent to user space is the mach port with send rights. As this requires access to the opaque parts of the semaphore_t structure, it is not a supported interface. It sure would be nice if this was supported or something like it. ...Duane On Jun 23, 2009, at 11:13 AM, Duane Murphy wrote: * PGP Signed: 06/23/09 at 11:13:32 I've done some more work on this and could use some recommendations on how to make this work. My first attempt was to simply pass the semaphore_t from the kernel back to the app. That didn't work at all. I went back to the 32-bit app and the old code and noticed that the semaphore_t in user space does not appear to be the semaphore_t from the kernel. There must be some massaging going on somewhere. What kind of massaging is happening so that I can get this to work. Thanks for the help, On Jun 19, 2009, at 12:27 PM, Duane Murphy wrote: Is there a replacement or recommendation for a replacement for io_connect_get_notification_semaphore() for 64-bit clients to an IOUserClient? We were using io_connect_get_notification_semaphore() in our 32-bit client side interface to our kext. It makes sense that this doesn't work in LP64 (semphore* would be a problem). Is there a recommended method for doing this ourselves? Is there a new and exciting interface wired to IOUserClient::getNotificationSemaphore()? ...Duane * Duane Murphy <duanemurphy(a)mac.com> * 0x10E2BD82(L) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/duanemurphy %40mac.com ...Duane -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) Charset: US-ASCII _______________________________________________ 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.… What are you using the notification semaphore for? Perhaps you can find a replacement with one of the supported IOKit user client functions, e.g., asynchronous methods or notifications. Old Signed: 06/19/09 at 12:27:20 This email sent to duanemurphy(a)mac.com wsBVAwUBSkFJ9Erg9acQ4r2CAQicHwf/Z8Qf8B8h1VsjdDsa7o9SZr8L5+leyHmw 2hIxU1KpNqh45a2K8+TlrQBJvavfc9br2PTDwshg4IK3JKprTVh1h+6omDsjeL2E /s+7Rj6kHUQzZOG0lMyGNyUk7MPY9LKeP+MKqoSuF6UcI2fLWnFkDSzXzevQm+AM MU+kkn/RQbwuRwt99tWxI/sfwwY0HCTPMtagVSQ7CF9wCzWhsw2KQYH4Qd1Kse6i 7EiUMV+6g2UksKsanQG80vfonVby0asjM+ea5i2iY4r0SErxkPfe4dhOb71B67/F 142FDpxW9ytHLIcddn8MIEMIFS6cHN1dFbFP/4DhN65Mg0LziPYIMA== =8wJE -----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/akosut %40apple.com This email sent to akosut(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: io_connect_get_notification_semaphore and x86_64
by Duane Murphy 23 Jun '09

23 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 (moving to darwin-kernel in the hopes that someone here might be able to help.) I now know how this works, but it is unclear why this is not being supported for 64-bit kernels. It would be nice if someone at Apple could comment, otherwise, it's going to cost me a DTS incident and a lot of work. :-( io_connect_get_notification_semaphore() is mig generated. The semaphore_t type has special mig handlers for incoming translation, outgoing translation and destruction. The opaque semaphore_t structure contains the mach port. The data sent to user space is the mach port with send rights. As this requires access to the opaque parts of the semaphore_t structure, it is not a supported interface. It sure would be nice if this was supported or something like it. ...Duane On Jun 23, 2009, at 11:13 AM, Duane Murphy wrote: > * PGP Signed: 06/23/09 at 11:13:32 > > I've done some more work on this and could use some recommendations > on how to make this work. > > My first attempt was to simply pass the semaphore_t from the kernel > back to the app. That didn't work at all. > > I went back to the 32-bit app and the old code and noticed that the > semaphore_t in user space does not appear to be the semaphore_t from > the kernel. There must be some massaging going on somewhere. > > What kind of massaging is happening so that I can get this to work. > > Thanks for the help, > > On Jun 19, 2009, at 12:27 PM, Duane Murphy wrote: > >> > Old Signed: 06/19/09 at 12:27:20 >> >> Is there a replacement or recommendation for a replacement for >> io_connect_get_notification_semaphore() for 64-bit clients to an >> IOUserClient? >> >> We were using io_connect_get_notification_semaphore() in our 32-bit >> client side interface to our kext. It makes sense that this doesn't >> work in LP64 (semphore* would be a problem). >> >> Is there a recommended method for doing this ourselves? Is there a >> new and exciting interface wired to >> IOUserClient::getNotificationSemaphore()? > > ...Duane > > > > > * Duane Murphy <duanemurphy(a)mac.com> > * 0x10E2BD82(L) > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-dev/duanemurphy > %40mac.com > > This email sent to duanemurphy(a)mac.com ...Duane -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.10.0 (Build 500) Charset: US-ASCII wsBVAwUBSkFHo0rg9acQ4r2CAQjTPwf/SBse6foZMrgn1yhQEQUWtmpvxPzlwDhr vl4rv+VgcmOM8uIxZv/Lr0UizNsTsjCqZuaH1IT7qV48upo5DC680YdGiryjeHKY ajeRxDGDEG/tsHP9wBSFtvhMTzfe7Q43FjQHXGFeXXQ1m75qdk5mHBd3zJYF8cVS ve7QNF0qNCrrYf1C5ybuasObv51UMa42r62lb0XdxhrYNE3J27R+UgPnSj4aA/3I G0PMR919A0rlIh3sa/Z+2LatZuq7TsOUfW56EjXo22hyvEgNs2Q75c6IFOtzfxID HPIJPIxLn8BBMoT2TaULR6H49WbA7n0MMSw6DDrbaSoK6KniRRaVew== =sRdx -----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.… This email sent to site_archiver(a)lists.apple.com

1 0

Which code creates the IODeviceTree?
by Thomas Tempelmann 23 Jun '09

23 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=5m67CcxyfmMbtTZZj05gMzV0/Ww6P7vW1I7spdRBxqo=; b=IaKxPJ8ycr360moF0MSvuaqOLyO/19n+wF1iu+SZA5D54XyoYpdBoQhetjsLd+wK2C rpxEBqMFDpaJAe1LUTXmd+6F/0M0pZ87k7M+4U5Lar2aPQaU6N+2eFmrcQaA7yd9a8yf AUiBUk5ZYUliex+T3tSnWC971bl4o15RyApEY= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=gHBpibPayJxWkH+MgjM4QRGJtcv159onRLzbCf7HUzW7CYUEEHPy9Y6F6IZTa/wNvr cMNjy03d2Ab9YLWOBC92k+sRVwsEZROc87DZcGEQDzt8jc66X8Q1zsFPUWilYncimwty m37580CI9+8M2o/c8HCTWRAtOMTcUbbWKRyY4= I've been looking for hours for an answer to this, please help: IO Device / kext matching is done via the Device Tree, as far as I know. And the device tree, according to Amit Singh's book, exists already before the kernel gets started. Hence, either the Open Firmware / EFI ROM or the bootloader must be creating it and pass it to the kernel, doesn't it? Since I want to see if I can patch the tree before the kernel starts matching kexts on it, I need to find the code that creates it in memory and passes it to the kernel. I've looked at the boot loader code but cannot find anything that does this. Does someone know how this actually works? -- Thomas Tempelmann, http://www.tempel.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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Easy way to access files from kernel space
by mm w 23 Jun '09

23 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=xTWvV0bYe0aHoNVrua1/lQGaguVNhMNFEYpuFb/0B3M=; b=JABqhdye22kTFrw+hDbtKmshfZOvbttbCO3o34ggbFdve2jWUYCydLJT58weOG45Na DkedFh92mDOy/sN91lDCZACwKq85QvL5wrfQOC48P5/K+hG+9t4fezqxXPVE/V1f4EcO G2xwXqZtZhQiH1iMfoERXVSBxnzRc+qdZI2Nk= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=E0QrSps5UO+1R+b8OedrlLCbDzUwta+TxItw2ljXzpIfnyxO1jpeFQpbGt4rGaHXty 0KRQ7cVegnS4UulKvljctd3KFT6RVUB6BUqAICjvRxsBNiH5pcEA9OZqLHmgvdXzwsSp ffikwEb2XIbpwONcHwmIeFnvQZGL50kXNQ6GA= Hello, no, you cannot manipulate file as file descriptor into a kernel, you may manipulate file system objects, you can also work with a demon-client in the user-space. http://developer.apple.com/samplecode/EmptyFS/listing4.html, this example doesn't exactly fit with your request but it has the advantage to answer to many pre-fundamental OS concepts. Best, On Tue, Jun 23, 2009 at 7:26 AM, evaluador evaluador<evaluador.evaluador(a)gmail.com> wrote: > Hello! > > Is there an easy way to access files from kernel space, so I could, for > example, copy a file from the kernel? > > Thank you! > > _______________________________________________ > 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/0xcafefeed%40gmail.com > > This email sent to 0xcafefeed(a)gmail.com > _______________________________________________ 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

Easy way to access files from kernel space
by evaluador evaluador 23 Jun '09

23 Jun '09

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Xilx2T25aaxFXwTL8nTT1GPeipKPQx6sV7GqTi2SPIw=; b=H1BSFs2T0gYBYu8bNG6IWAVG+OWN7km4r/KBlnQb+5M19NSlBMTukRPGNYwOYMCRwT wOIu3Bk2gF6nGxmUYNdLodzyde8PFphGoFtCNfQjOtUiW+KWf/4t4z0Ib5lN8tmmCHAm nzgxIQgeciohfVM3PQ2ZRZeX3qIXr6cmtDDBs= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gw2vto2n7XzvExQg6GkdUTrSfoxeRwSa/OWrNHEGevoPDC+AYIdu05at5pbbLAeKgh /waNnkSWR75kl5nAntGSNSNv/LYVu5BMTRKA39PKOOVQAS8n9AcBPbXrM7+WFcAUyH9B K1eFHHYuXJQgobORvYy0EOpmJC6ax95eGpDM0= _______________________________________________ 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