February 2008 - Darwin-dev - lists.apple.com

Re: WARNING: The module QTSSAccessModule is not a compatible QTSS API module.
by Terry Lambert 08 Feb '08

08 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, -- Terry _______________________________________________ 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/site_archiver%40lists.app… On Feb 8, 2008, at 12:37 AM, Werner PAblo Tornow wrote: how can I debug in the QTSSAccessModule (QTSS_Error AuthenticateRTSPRequest(QTSS_RTSPAuth_Params* inParams)) I wrote some Code to extract the session_id. If I want to debug the QTSSAccessModule, I get some Error "WARNING: The module QTSSAccessModule is not a compatible QTSS API module" I can debug the server & and QTSSAccess log Module (Vista, Visual Studio 2005) and also it is extracting the session_id from QTSSAccessModule but if I set some Breakpoint in the QTSSAccessModule it is inactive and I dont now how to jump in it. Hope anybody can help. Thanks Streaming-server-dev: Discussion list for QuickTime Streaming Server developers. Streaming-server-users: Discussion list for QuickTime Streaming Server users. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Swapping Kernel Memory?
by Jim Magee 08 Feb '08

08 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Feb 7, 2008, at 4:01 PM, Terry Lambert wrote: --Jim _______________________________________________ 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/site_archiver%40lists.app… On Feb 7, 2008, at 11:00 AM, Duane Murphy wrote: Do I have to do anything special to prevent memory allocated by an IOKit kext from getting swapped out? I have some memory that I would like to never be paged out to VM. Do I have to do anything special to make that happen? Or is that memory already prevented from swapping? Kernel memory is wired. That's why you should use as little as possible, since when you allocate kernel memory, you are eating a chunk of the kernel virtual address space, which is a scarce resource. Actually, it depends what API you used to allocate the memory. Most in-kernel allocations are wired automatically, but not all. This email sent to site_archiver(a)lists.apple.com

1 0

WARNING: The module QTSSAccessModule is not a compatible QTSS API module.
by Werner PAblo Tornow 08 Feb '08

08 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Importance: Normal _______________________________________________ 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/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Shared Memory and login sessions
by Terry Lambert 08 Feb '08

08 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Terry _______________________________________________ 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/site_archiver%40lists.app… On Feb 7, 2008, at 3:23 PM, Andy Klepack wrote: I’m curious whether there is any guarantee that leaked shared memory is reclaimed when a user logs out. If a region is opened via shm_open but not closed before the user logs out, is that memory reclaimed by the OS or does it persist until reboot? My suspicion is that it is not reclaimed since there is no assurance that the sharing processes are all running in the user’s session, but a definitive answer would be great. It is a persistent object, so unless you explicitly destroy it, it will effectively persist forever (or until the next reboot, or until the segment is explicitly deleted by another process). There is lots of documentation on how to implement shared memory using System V shared memory, POSIX shared memory (which is what you are talking about when you talk about shm_open), and mmap(). I typically suggest using mmap(), since there are no resource tracking cleanup issues with mmap(), as there are with the others. You can also hand around memory maps between processes using Mach primitives, which will be resource tracked and cleaned up when the last reference goes away. Which method you choose really depends on whether or not your process is intended to be runnning all the time, and if so, whether it is intended to resynchronize or delete and recreate the mapping when it restarts. Typicially, people who choose to go the POSIX shared memory (shm_open) route register atexit() handlers and signal handlers so that if the process dies, it will clean up after itself. Otherwise they pick some other method of sharing memory. This email sent to site_archiver(a)lists.apple.com

1 0

Shared Memory and login sessions
by Andy Klepack 07 Feb '08

07 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: Achp4GXYtGOzYDIQQqiRZAn6wwLofg== Thread-topic: Shared Memory and login sessions _______________________________________________ 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/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Swapping Kernel Memory?
by Terry Lambert 07 Feb '08

07 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com I have some memory that I would like to never be paged out to VM. Do I have to do anything special to make that happen? Or is that memory already prevented from swapping? -- Terry _______________________________________________ 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/site_archiver%40lists.app… On Feb 7, 2008, at 11:00 AM, Duane Murphy wrote: Do I have to do anything special to prevent memory allocated by an IOKit kext from getting swapped out? Kernel memory is wired. That's why you should use as little as possible, since when you allocate kernel memory, you are eating a chunk of the kernel virtual address space, which is a scarce resource. This email sent to site_archiver(a)lists.apple.com

1 0

Swapping Kernel Memory?
by Duane Murphy 07 Feb '08

07 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Do I have to do anything special to prevent memory allocated by an IOKit kext from getting swapped out? I have some memory that I would like to never be paged out to VM. Do I have to do anything special to make that happen? Or is that memory already prevented from swapping? Thanks, ...Duane _______________________________________________ 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/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Ancillary data and 32/64 bit processes
by Michael Tuexen 06 Feb '08

06 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Terry, Thanks for letting me know. Best regards Michael On Feb 6, 2008, at 1:14 AM, Terry Lambert wrote: -- Terry Hi Terry, it would be very nice if your fix and an appropriate fix for the CMSG_* macros could go into some update of Mac OS X 10.5.?. Best regards Michael On Feb 4, 2008, at 10:33 PM, Terry Lambert wrote: Hi Kevin, see my comments in-line. Best regards Michael On Feb 4, 2008, at 7:18 AM, Kevin Van Vechten wrote: On Feb 3, 2008, at 11:15 AM, Michael Tuexen wrote: I habe a problem using ancillary data on 64-bit processes... The macro CMSG_DATA ist defined in /usr/include/sys/socket.h as I can provide a simple UDP discard server which shows this bug. This problem is crucial for our SCTP NKE, which uses ancillary data a lot... -- Terry _______________________________________________ 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/site_archiver%40lists.app… thanks for the note. We will work around this bug in our code and I will add a release note that people using CMSG_ macros in 64bit applications should update to 10.6.0 or a newer version of XCode when it becomes available. In my experience, header fixes are typically only released with an XCode/SDK release or a full OS release, rather than in software updates. On Feb 4, 2008, at 11:16 PM, Michael Tuexen wrote: On Feb 4, 2008, at 12:20 PM, Michael Tuexen wrote: #define CMSG_DATA(cmsg) ((unsigned char *)(cmsg) + \ __DARWIN_ALIGN(sizeof(struct cmsghdr))) __DARWIN_ALIGN behaves different on 32-bit processes and 64-bit processes. Therefore the offset of the CMSG_DATA is 12 bytes on 32-bit processes and 16 byte on 64-bit processes. However, the kernel ignores this difference and puts the CMSG_DATA at a 12 byte offset. User processes may be 32-bit or 64-bit, but the kernel always executes in a 32-bit address space. Yes, that is the cause of the problem. Therefore programs using ancillary data work, when compiled for 32-bit, but do not work when compiled for 64-bit. Is this a known bug? Please file a bug <http://developer.apple.com/bugreporter/>. Even if it's a known issue, additional reports help us gauge the overall impact of the issue. (A quick check didn't find any issues reported against CMSG_DATA or DARWIN_ALIGN.) Done, Bug ID# 5723161 Should it be fixed by changing the CMSG_DATA macros to behave the same on 32-bit and 64-bit processes or should the kernel be changed to adjust the ancillary data? I suspect the former, since that would preserve the binary compatibility expectations of 64-bit processes with today's kernel. OK, sounds fine. As a workaround, you could define your own CMSG_DATA macro. Yes, for the code we write... To enable a programmer to use the macros we need to patch /usr/include/sys/socket.h... #pragma pack(4) struct cmsghdr { socklen_t cmsg_len; /* [XSI] data byte count, including hdr */ int cmsg_level; /* [XSI] originating protocol */ int cmsg_type; /* [XSI] protocol-specific type */ /* followed by unsigned char cmsg_data[]; */ }; #pragma pack() You never have an array of cmsghdr, due to cmsg_data[]. If this were strict C99 code, it wouldn't compile in CodeWarrior, which doesn't grok correct C99 syntax, but cmsg_data[] would be there as an unsized array for use with __offsetof() (probably named __cmsg_data[] to keep it out of the POSIX namespace and make it visible to the macros that POSIX requires). If you don't do the packing, then the offset of the header will differ between the 64 bit user space and the 32 bit kernel space, and you will effectively start 4 bytes late in the 64 bit code, which will still cause you problems. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Darwin 8.11 and 9.1 Source
by Axel Luttgens 06 Feb '08

06 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 1 févr. 08 à 01:51, William Siegrist a écrit : The following projects have been posted: xar-28 WebCore-5523.10.3 Hello Bill, Once again, thanks a lot! Axel _______________________________________________ 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/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Ancillary data and 32/64 bit processes
by Terry Lambert 06 Feb '08

06 Feb '08

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Terry Hi Terry, it would be very nice if your fix and an appropriate fix for the CMSG_* macros could go into some update of Mac OS X 10.5.?. Best regards Michael On Feb 4, 2008, at 10:33 PM, Terry Lambert wrote: Hi Kevin, see my comments in-line. Best regards Michael On Feb 4, 2008, at 7:18 AM, Kevin Van Vechten wrote: On Feb 3, 2008, at 11:15 AM, Michael Tuexen wrote: I habe a problem using ancillary data on 64-bit processes... The macro CMSG_DATA ist defined in /usr/include/sys/socket.h as I can provide a simple UDP discard server which shows this bug. Should it be fixed by changing the CMSG_DATA macros to behave the same on 32-bit and 64-bit processes or should the kernel be changed to adjust the ancillary data? This problem is crucial for our SCTP NKE, which uses ancillary data a lot... -- Terry _______________________________________________ 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/site_archiver%40lists.app… In my experience, header fixes are typically only released with an XCode/SDK release or a full OS release, rather than in software updates. On Feb 4, 2008, at 11:16 PM, Michael Tuexen wrote: On Feb 4, 2008, at 12:20 PM, Michael Tuexen wrote: #define CMSG_DATA(cmsg) ((unsigned char *)(cmsg) + \ __DARWIN_ALIGN(sizeof(struct cmsghdr))) __DARWIN_ALIGN behaves different on 32-bit processes and 64-bit processes. Therefore the offset of the CMSG_DATA is 12 bytes on 32-bit processes and 16 byte on 64-bit processes. However, the kernel ignores this difference and puts the CMSG_DATA at a 12 byte offset. User processes may be 32-bit or 64-bit, but the kernel always executes in a 32-bit address space. Yes, that is the cause of the problem. Therefore programs using ancillary data work, when compiled for 32-bit, but do not work when compiled for 64-bit. Is this a known bug? Please file a bug <http://developer.apple.com/bugreporter/>. Even if it's a known issue, additional reports help us gauge the overall impact of the issue. (A quick check didn't find any issues reported against CMSG_DATA or DARWIN_ALIGN.) Done, Bug ID# 5723161 I suspect the former, since that would preserve the binary compatibility expectations of 64-bit processes with today's kernel. OK, sounds fine. As a workaround, you could define your own CMSG_DATA macro. Yes, for the code we write... To enable a programmer to use the macros we need to patch /usr/include/sys/socket.h... #pragma pack(4) struct cmsghdr { socklen_t cmsg_len; /* [XSI] data byte count, including hdr */ int cmsg_level; /* [XSI] originating protocol */ int cmsg_type; /* [XSI] protocol-specific type */ /* followed by unsigned char cmsg_data[]; */ }; #pragma pack() You never have an array of cmsghdr, due to cmsg_data[]. If this were strict C99 code, it wouldn't compile in CodeWarrior, which doesn't grok correct C99 syntax, but cmsg_data[] would be there as an unsized array for use with __offsetof() (probably named __cmsg_data[] to keep it out of the POSIX namespace and make it visible to the macros that POSIX requires). If you don't do the packing, then the offset of the header will differ between the 64 bit user space and the 32 bit kernel space, and you will effectively start 4 bytes late in the 64 bit code, which will still cause you problems. This email sent to site_archiver(a)lists.apple.com

1 0