August 2006 - Darwin-dev - lists.apple.com

Re: Launchd domain socket permission problem
by Dave Zarzycki 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Aug 4, 2006, at 1:58 PM, Peter Bierman wrote: davez _______________________________________________ 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… My first guess would be the umask. For that to be involved, you might be creating the socket from a script instead of as part of your package payload. Either have your application create the socket at runtime and assign correct permissions then, or make the socket part of your package payload. Agreed. Although as the launchd maintainer, I'd rather see the socket created as a part of the launchd job schema outlined in the property list, but that is my personal agenda. :-P This email sent to site_archiver(a)lists.apple.com

1 0

Re: Launchd domain socket permission problem
by Peter Bierman 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -pmb _______________________________________________ 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… At 11:01 AM -0700 8/4/06, Kevin Brock wrote: I've got a launchd daemon that uses a domain socket for communicating with applications. On some (most) systems it installs and runs fine. The socket permissions are 140777 octal, so that anyone on the system can access the services the daemon is offering. On some customer systems the same install package ends up creating a domain socket with permissions 140755 octal, which means that normal users can't talk to that socket. It's the same install packet in both cases, and the permissions and locations of the .plist file and daemon binary are the same, and the directory permissions for the domain socket directory and it's parent are the same in all cases. Does anyone have a clue about why this might be happening? If this is an Apple Installer package (.pkg or .mpkg) then the question might be better asked on the installer-dev(a)lists.apple.com mailing list. My first guess would be the umask. For that to be involved, you might be creating the socket from a script instead of as part of your package payload. Either have your application create the socket at runtime and assign correct permissions then, or make the socket part of your package payload. This email sent to site_archiver(a)lists.apple.com

1 0

Mach-O Runtime PDF on ADC
by Mark Stultz 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Microsoft-Entourage/11.0.0.040405 Hello, I am currently investigating the Mach-O file format. I was reading the revision history in "Mac OS X ABI Mach-O File Forma Reference" (MachORun.pdf), and noticed it stated: "By popular demand, added some common usage scenarios to map runtime features to the options in the standard Mac OS X tools that implement those features. To satisfy a related popular demand, this information is collected in a separate chapter, which allows users of third-party tool sets to ignore it. This chapter is currently unfinished, and the overview chapter is yet to be modified to cross-reference it." It says that the information is in another chapter, and that it is unfinished. I don't see it referenced at all in the revision, and I am curious if this has been published and/or is in another document. It is dated 2002, and so I'm sure I must be overlooking something. Mark _______________________________________________ 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

Launchd domain socket permission problem
by Kevin Brock 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Does anyone have a clue about why this might be happening? Any suggestions would be appreciated. Kevin Brock apple(a)kevin.com _______________________________________________ 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… I've got a launchd daemon that uses a domain socket for communicating with applications. On some (most) systems it installs and runs fine. The socket permissions are 140777 octal, so that anyone on the system can access the services the daemon is offering. On some customer systems the same install package ends up creating a domain socket with permissions 140755 octal, which means that normal users can't talk to that socket. It's the same install packet in both cases, and the permissions and locations of the .plist file and daemon binary are the same, and the directory permissions for the domain socket directory and it's parent are the same in all cases. This email sent to site_archiver(a)lists.apple.com

1 0

Re:Non-priv way to collect job stats under Intel?
by Jeffrey Johnson 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 8/2/06 at 12:02 PM, darwin-dev-request(a)lists.apple.com wrote: >> >Does sysctl on kern.proc work for this? (See the example in the >>>sysctl 3 man page.) >>> >>>I grabbed some source described here: >>>http://ezine.daemonnews.org/200205/sysctl-netbsd.html >>> >>>I had to change some "struct proc" declarations to "struct >>>extern_proc", but then it compiles. Running it against my local user >>>didn't correctly sum up my CPU usage, but it did correctly count my >>>processes. >> >>Thanks for the link.. but I encountered the same result, it didn't >>return the CPU usage (just zeros), so I wonder if it suffers from >>the same "can't get stats from a running process" limitation as >>getrusage(). I pulled it into gdb and looked at the extern_proc >>p_rtime and p_cputicks fields. (Heck, I showed the whole struct and >>every time-like field was empty except __p_starttime.) >> > >I think this is an OS bug. Please file a radar bug about this issue, >as an external need carries more weight. > >-pmb Done- filed as <rdar://4667814>. Thanks Jeffrey Johnson Macintosh Development Wavefunction, Inc. _______________________________________________ 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: Total RAM slot count obtained programatically
by Jonas Maebe 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 4 aug 2006, at 11:04, Roberto Cruz wrote: Jonas _______________________________________________ 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… Let put in other way, if no memory installed nor information, I removed one and it's ok too, If no info provided then no memory installed, I don't understand what the problem is, to check the dimm configuration is simple with this tool. As far as I understand he need to know the configuration and get the population of DIMMs, well for filled DIMMs the system report the info, if no dimm on one slot only info about the installed is provided, ok, if no dimm on both no problem you can not but the machine. He wants to know (programmatically) how many dimm *slots* there are in the system (as the subject of this thread says), regardless of whether they are populated with DIMMs or not. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Total RAM slot count obtained programatically
by Roberto Cruz 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Aug 4, 2006, at 9:51 AM, Jonas Maebe wrote: On 3 aug 2006, at 23:28, Roberto Cruz wrote: Works on MB Pro and MB system_profiler SPMemoryDataType Memory: DIMM0/BANK 0: Size: 1 GB Type: DDR2 SDRAM Speed: 667 MHz Status: OK DIMM1/BANK 1: Size: 1 GB Type: DDR2 SDRAM Speed: 667 MHz Status: OK Jonas _______________________________________________ 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/rcp%40cryptonome.com This email sent to rcp(a)cryptonome.com _______________________________________________ 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… Let put in other way, if no memory installed nor information, I removed one and it's ok too, If no info provided then no memory installed, I don't understand what the problem is, to check the dimm configuration is simple with this tool. As far as I understand he need to know the configuration and get the population of DIMMs, well for filled DIMMs the system report the info, if no dimm on one slot only info about the installed is provided, ok, if no dimm on both no problem you can not but the machine. Perhaps it's a problem with your kexts As far as I understood the issue is to get information about dimm slots which don't have memory installed. Both your slots are filled with memory apparently. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Total RAM slot count obtained programatically
by Jonas Maebe 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 3 aug 2006, at 23:28, Roberto Cruz wrote: Works on MB Pro and MB system_profiler SPMemoryDataType Memory: DIMM0/BANK 0: Size: 1 GB Type: DDR2 SDRAM Speed: 667 MHz Status: OK DIMM1/BANK 1: Size: 1 GB Type: DDR2 SDRAM Speed: 667 MHz Status: OK Jonas _______________________________________________ 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… Perhaps it's a problem with your kexts As far as I understood the issue is to get information about dimm slots which don't have memory installed. Both your slots are filled with memory apparently. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Problems with open() and close()
by Godfrey van der Linden 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com You are using pseudo-terminals, not serial port is that correct? Godfrey On 04/08/2006, at 2:34 AM, Cem Karan wrote: Thanks for any help, Cem Karan boolean_t open_TTY_OSX(char *devicePath, OSX_TTYcontext context) { size_t counter; adjAssert((devicePath != NULL) && (context != NULL)); if ((devicePath == NULL) || (context == NULL)) return false; if (ioctl(context->fileDescriptor, TIOCEXCL) == -1) { ERROR_CLOSE_FD_TTY_OSX_PRIVATE(context->fileDescriptor); return false; } if (fcntl(context->fileDescriptor, F_SETFL, 0) == -1) { ERROR_CLOSE_FD_TTY_OSX_PRIVATE(context->fileDescriptor); return false; } if (fcntl(context->fileDescriptor, F_NOCACHE, 1) == -1) { ERROR_CLOSE_FD_TTY_OSX_PRIVATE(context->fileDescriptor); return false; } for (counter = 0; counter < NCCS; counter++) (context->current).c_cc[counter] = _POSIX_VDISABLE; cfmakeraw(&(context->current)); (context->current).c_cc[VMIN] = 1; (context->current).c_cc[VTIME] = 1; cfsetspeed(&(context->current), B57600); /* Set 57600 baud */ (context->current).c_cflag |= (CS8 | CREAD | CLOCAL); return true; } void close_TTY_OSX(OSX_TTYcontext context) { int result; adjAssert(context != NULL); if (tcdrain(context->fileDescriptor) == -1) { printf("Error waiting for drain - %s(%d).\n", strerror(errno), errno); } if (ioctl(context->fileDescriptor, TIOCNXCL) == -1) { ERROR_CLOSE_FD_TTY_OSX_PRIVATE(context->fileDescriptor); } result = close(context->fileDescriptor); if (result != 0) perror(NULL); } _______________________________________________ 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/gvdl%40mac.com _______________________________________________ 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 this case the exclusive flag doesn't get cleared until both sides of the port get closed. On a serial port the t_state variable is set to 0 on close, but you pseudo-terminals are sort of 2 serial ports in one and they share most of their state. Hi all, first time poster to this list, hope that this is right list to post to... I've adapted some code to my own uses (shown below) but have run into an odd problem, and I'm hoping that someone can explain what is going on to me. As a part of my open_TTY_OSX() function, I call ioctl(context->fileDescriptor, TIOCEXCL), which prevents any non- root program from opening the same device. Now this is where it gets odd for me. I am testing all this code using some unit tests that I wrote. The unit tests call open_TTY_OSX() and then balance the call with a call to close_TTY_OSX() on the same file descriptor. Originally, I did NOT have the ioctl(context- >fileDescriptor, TIOCNXCL) call in close_TTY_OSX(), and the result was that if I tried to open the same device again, it would fail with EBUSY. So basically: open_TTY_OSX("/dev/ttyp1", foo) // no problem close_TTY_OSX(foo) // no problem open_TTY_OSX("/dev/ttyp1, bar) // Fails with EBUSY Well, I figured that this isn't that big a deal, I just let my process exit nicely, and the restart the debugging session, right? No good. The only way for me to make things play nice is to quit XCode, and even that doesn't seem to work 100% of the time. My question is why? When I close, I reset the attributes, and I close () the descriptor. That should make the blocking part go away, right? What am I doing wrong? Oh, note that adjAssert() is a macro like assert(); I just hacked in some extra stuff that I needed, and didn't what the names conflicting. #define ERROR_CLOSE_FD_TTY_OSX_PRIVATE (FD) \ { \ struct stat myStat; \ perror (NULL); \ fflush (stderr); \ fflush (stdout); \ if (FD != -1) \ { \ printf("Closing file descriptor"); \ fstat(FD, &myStat); \ close (FD); \ } \ } context->fileDescriptor = open(devicePath, O_RDWR | O_NOCTTY | O_NONBLOCK); if (context->fileDescriptor == -1){ ERROR_CLOSE_FD_TTY_OSX_PRIVATE(context->fileDescriptor); return false; } if (tcgetattr(context->fileDescriptor, &(context->original)) == -1) { printf("Error getting tty attributes %s - %s(%d).\n", devicePath, strerror(errno), errno); ERROR_CLOSE_FD_TTY_OSX_PRIVATE(context->fileDescriptor); return false; } memcpy(&(context->current), &(context->original), sizeof(struct termios)); if (tcsetattr(context->fileDescriptor, TCSANOW, &(context- >current)) == -1) { ERROR_CLOSE_FD_TTY_OSX_PRIVATE(context->fileDescriptor); return false; } if (tcsetattr(context->fileDescriptor, TCSANOW, &(context- >original)) == -1) { printf("Error resetting tty attributes - %s(%d).\n", strerror(errno), errno); } This email sent to gvdl(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Should getWorkLoop be thread-safe?
by Godfrey van der Linden 04 Aug '06

04 Aug '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Godfrey On 04/08/2006, at 12:10 AM, Howard Gayle wrote: return arSetWorkLoop; } Is there a race condition where two different threads could call getWorkLoop(), resulting in the unwanted creation of two different IOWorkLoop objects? _______________________________________________ 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/gvdl%40mac.com _______________________________________________ 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 function tends to get called at driver start time. start() is guaranteed to be single threaded so there isn't really a threading issue. Apple's "I/O Kit Fundamentals" guide http://developer.apple.com/documentation/DeviceDrivers/Conceptual/ IOKitFundamentals/index.html has an example under Handling Events > Work Loops > Listing 7-1 of overriding getWorkLoop(). The example tries to make getWorkLoop() thread-safe. I have some concerns about the example code, but does getWorkLoop() really need to be thread-safe? I couldn't find any real code that worries about this. The code in AppleRAIDSet.cpp in AppleRAID is pretty typical: IOWorkLoop * AppleRAIDSet::getWorkLoop(void) { // Create a WorkLoop if it has not already been done. if (arSetWorkLoop == 0) { arSetWorkLoop = IOWorkLoop::workLoop(); } This email sent to gvdl(a)mac.com This email sent to site_archiver(a)lists.apple.com

1 0