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

Some questions about DirectoryServices
by Eli Bach 24 Feb '09

24 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:subject:mime-version:date :x-mailer; bh=oAeGt5cTvSTAVFlQrlw3ljCMNTkDp/omvbxf2G2LSfs=; b=BP1f1om8ukPuJ3WaF5fJ0U6eitXLYxrDhr3ihDjH+iAuY+wFZ87EfJxHrK+qw8kgHq b4a6e+shoHUGKPQLsqoBkEUD2Dfd5Jvnm++fB2SrRV7K1gTu2gOlW2Qg0slJAUJrEXAo SgBtXm0ePjTe85iuBVAVutVEhfrfD1HqxrAAc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject :mime-version:date:x-mailer; b=Im5xnHCHfB/obwwJNLToPbUABpZFNV2BoN2/zJBtS7B+Dr+b/1wj7GSKbmsHgsmjWF iEJOPZx2TssuoeGu/70FXH6v6ogeiBvTbzJvUhpy+9yJNV3sv3JEydfMN9Hzy5X/YJbv ZOTHE1k7q+63wptFhgEjH2vyn9f+OaVomPftE= Or is there a better list to ask these questions? Thanks, Eli _______________________________________________ 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… 1. What is the preferred method to get DirectoryServices to re-read it's configurations files (in particular, it's LDAP configuration). Right now, I do a 'killall -TERM DirectoryService', which does the job, but in a relatively heavyhanded way. 2. Probably as a result of doing 1., accessing DirectoryServices soon after it is restarted will sometimes cause a dirReference to become valid. I'm doing more testing to see if it's all the time, or just sometimes, but after restarting DirectoryServices, at least sometimes other DS functions will return eDSInvalidReference for a reference that did work. I have a single function that manages a global dirReference that is used everywhere that one is needed (so dsOpenDirService() is called once, and that reference is saved for use by all called to DS. As a workaround to 2., I've added an extra check, namely a dsVerifyDirRefNum(), and if it fails, the function sleeps(), then calls dsOpenDirService() to get a new dirReference. Is this a reasonable workaround, or is there a better way to restart DS so the reference doesn't get invalidated? Or should I assume the dirReference becomes invalid whenever I restart DS (so I should clear the global value when DS is restarted)? Or is there a way to wait until DS has completely restarted before trying to access it? I'm configuring some ldap settings that the dsconfigldap cli tool doesn't support, which is why I need to get DS to reload the ldap configuration. And yes, I've noticed that it will reset some seemingly unrelated things, such as using teleportd to share a keyboard/mouse to another computer (so the keyboard/mouse go back to controlling their host, instead of the shared computer). This email sent to site_archiver(a)lists.apple.com

1 0

Re: ACL Inheritance?
by James Peach 24 Feb '09

24 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(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=pOtLPDyy+mUsk2JKnwlYE/IAn+C7q++85WIcxCzJ1us=; b=RhPrJTj9ifX9CzAxr0w862wZF0J8e7FsZDLmrLmNCWJvJ6+mp9J1PoFBhFSFUEnz7r cOQ0PrGtgPjxbZGOZbWNras7DoYilZoUU45/XITWBdoqXm7fZIDqOwhs4YnfFf+Qbhk5 Ab5h9okFeIwusv7dY5ySUgg8HzP6+GRlYvctA= 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=S786AI+v7fPmZGs8aSqPy99gW9q65Fges8Fa8a8F6D3KHPR/MYsq63WOl64HMULGSn zE5WkuInGpueXRcrZTM0KsGhwXrXCeC/jxOI29dmnK9sT9E39FqMPUHbb1b8cGx8gBP5 80NW/QTqnzJ7TxxIEIkzkKp7E81w2wICrkLUo= 2009/2/23 Jeremy S. Albrecht <jsalbre(a)gmail.com>: > Ben, > > Check out a program called Sandbox ( http://www.mikey-san.net/sandbox/ ) for > easy ACL work. When I have an issue similar to yours I basically set the > ACL as desired on the parent directory, tell it that it's inherited from > it's parent, and then propagate it to all subfolders, *then* take away the > "inherited" flag from the parent folder. A bit of a round-about way to do > it, but it works. If I understand what you are doing, I don't think it is the correct approach. The ACL at the root of an inheritance tree should have at least one ACE that is marked file_inherit or directory_inherit. When these ACEs are copied to child objects, they should be marked with the inherit bit. This is so that everyone else knows how the ACL inheritance tree is constructed and can reflow it. If you don't correctly maintain the inheritance bits, then it all just looks like a collection of direct ACEs to the system. The problem with this is that if someone comes along an adds just one direct ACE to something in the inheritance tree, then you can't reflow any more because you lost the information about which ACEs where inherited and which were not. -- James Peach | jorgar(a)gmail.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 email sent to site_archiver(a)lists.apple.com

1 0

Re: ACL Inheritance?
by James Peach 24 Feb '09

24 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(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=ONdrt14uqTmyoMWNF7IGmlm/O9vWSWqvMNbqajjXbp4=; b=JKVZrYU2hbsUkPqHX2iVcK9KqGRpeKmObV/wjZsKMJMW95r/k0Op1rXgtdYXL3INLZ 7pLrnja3uUn32pOhtcKTMn2nZ+yCIZPihsILkZvnh2TYz8/Fpfybq342XwtaPAWk0+Zz gkV2iJBcDPbycj5AJAj52qev3rYhZBUOy95RU= 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=cEu4809WtieTEjH4ppYBIjE4QgxTsFSdtWfJGJugyJ4j0YVc4KVzyu7yPPO+DDYhSt u6JG1c6hEwwXSXbZPLVhRwO8/KzzX9HcKV5cPnGkeOL1mtpEjQF3pRROVmBsZegqqB5p snUVlGlbpJXucuQkEWA7h0JFgeijwR8ujud3k= 2009/2/20 Benjamin Huntsman <BHuntsman(a)mail2.cu-portland.edu>: > Hi all! > > This may not be the right list, but perhaps someone could point me in the right direction regarding ACL's on Mac OS X... > > I've got an XServe running 10.4, with an attached Xserve RAID. The raid array is running XSan, and mounted as a single volume under /Volumes. The Xserve is joined to an Active Directory domain, which it uses for authentication. > > The folders at the root of the XSan volume are configured as SMB shares, so that Windows clients can access them. > > So here's the catch... we want to have a certain group in the Active Directory domain control access to one of the folders on the Xsan volume. When the server was set up, they were using UNIX permissions (user, group, others) to configure access, which became problematic as more and more users were added to the system. Switching to ACL's after the fact though, hasn't worked very well. > > The Active Directory group is added in Workgroup Manager to the folder, and set to propagate, but it doesn't do so to all subfolders, especially those that were present before the change. I set up a test volume on a dmg to experiment via the command line, and found that if you set an ACL with inheritance on a folder that ALREADY contains a subfolder, the subfolder won't automatically inherit the ACL from it's parent, but all subsequently created folders or files will. > > So my question is, is there a way, via the command line or otherwise, to essentially tell a folder or file to "re-inherit" it's ACL list from it's parent? Somewhere in the ServerAdmin permissions editor there is a checkbox that makes it reflow the inherited ACL throughout the share point. It might be Leopard-only, I can't remember off the top of my head. -- James Peach | jorgar(a)gmail.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 email sent to site_archiver(a)lists.apple.com

1 0

Re: ACL Inheritance?
by Jeremy S. Albrecht 24 Feb '09

24 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=RESpLIilQcHX9CJVXCTtW61cDtEb4A9tqRU2+hJEf24=; b=Rcf8VANZeg+SUKpJE7UIXOvRHTUiU/IC4uLw7Sfe1Iiy+N9TYMCDsgItB0BYoG2t1B xHXS6tFdOsFGv/L9H3rhCRF53pioGEBPLiFVWLMjK47+3UYwxdeDYag3F2gH1gDo8P26 2d/Kw8ZKYYaPkEcdRYbXibAt1uQM5OchIODto= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=nQ6bkE57ApHjjNjalA+PuoFkTFm4wDq/Fx5JSYNasz90+9ko771UGE0tQHX/HP63xy Cr3dEZlwfHmHpPcL49wr92071MhQKsk2sKnvOrRM1/rtjCAExNeSE7K6GNQbdgUaN81x BAFXgWtW1qd3yra9cSpvO6NYzYHcd1pvw35Cc= Ben, Jeremy S. Albrecht http://c0dedbad.com On 20 Feb 2009, at 17:32, Benjamin Huntsman wrote: Hi all! Many thanks to all in advance!! _______________________________________________ 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… Check out a program called Sandbox ( http://www.mikey-san.net/ sandbox/ ) for easy ACL work. When I have an issue similar to yours I basically set the ACL as desired on the parent directory, tell it that it's inherited from it's parent, and then propagate it to all subfolders, *then* take away the "inherited" flag from the parent folder. A bit of a round-about way to do it, but it works. This may not be the right list, but perhaps someone could point me in the right direction regarding ACL's on Mac OS X... I've got an XServe running 10.4, with an attached Xserve RAID. The raid array is running XSan, and mounted as a single volume under / Volumes. The Xserve is joined to an Active Directory domain, which it uses for authentication. The folders at the root of the XSan volume are configured as SMB shares, so that Windows clients can access them. So here's the catch... we want to have a certain group in the Active Directory domain control access to one of the folders on the Xsan volume. When the server was set up, they were using UNIX permissions (user, group, others) to configure access, which became problematic as more and more users were added to the system. Switching to ACL's after the fact though, hasn't worked very well. The Active Directory group is added in Workgroup Manager to the folder, and set to propagate, but it doesn't do so to all subfolders, especially those that were present before the change. I set up a test volume on a dmg to experiment via the command line, and found that if you set an ACL with inheritance on a folder that ALREADY contains a subfolder, the subfolder won't automatically inherit the ACL from it's parent, but all subsequently created folders or files will. So my question is, is there a way, via the command line or otherwise, to essentially tell a folder or file to "re-inherit" it's ACL list from it's parent? I can do 'chmod -R +a "<acl>" folder', but that's not what we're after... -Ben This email sent to site_archiver(a)lists.apple.com

1 0

Re: Developer available
by Alexander v. Below 21 Feb '09

21 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.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 email sent to site_archiver(a)lists.apple.com

1 0

Re: GCC stack size
by Ryan McGann 21 Feb '09

21 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Ryan On Feb 20, 2009, at 10:07 PM, Eric Gouriou wrote: On Feb 20, 2009, at 4:15 PM, Ryan McGann wrote: What are your compile options, besides -O3 ? Eric Thanks, Ryan _______________________________________________ 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/eric.gouriou%40pobox.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… Correction to my last post: I am learning i386 assembly as I go, and wasn't looking at the usage of the EBP register. The EBP register's (negative) offsets can be quite large: 00004038 movl 0xffffff5c(%ebp),%eax 0000403e movl %eax,0xfffffc48(%ebp) 00004044 movl 0x10(%ebp),%eax 00004047 movl 0x18(%eax),%eax 0000404a movl %eax,0xfffffc50(%ebp) 00004050 movl 0,0xfffffc54(%ebp) 0000405a movl 0xffffff64(%ebp),%eax 00004060 movl (%eax),%edx 00004062 movl 0x04(%eax),%ecx 00004065 movl %edx,0xfffffc58(%ebp) 0000406b movl %ecx,0xfffffc5c(%ebp) 00004071 movl 0xfffffc5c(%ebp),%ecx 00004077 cmpl %ecx,0xfffffc54(%ebp) 0000407d jbl 0x00004156 So values from the ESP don't go beyond the 24 byte range but I see plenty of movl addressing (-939)%ebp. Ouch. A couple weeks ago I asked about a machine-check panic I was getting. As it turns out, my suspicions were right about stack corruption. I disassembled a function in our kext and saw that for some reason, GCC's function prologue was allocating around 1660 bytes of stack (in release, debug was slightly better at 1140 bytes). On other platforms compiled with GCC (FreeBSD and many different Linux distros) the stack usage is near 110 bytes, but for some reason gcc on Mac OS X is allocating almost 4K. We are currently using -O3 because the code is pretty compute- bound, and on other platforms -O3 has a nice 5% boost compared to - O2. But changing it to -O2 doesn't even help, we have to go all the way to -O1 to get a usable stack of 400 bytes (still 4x larger than our Linux driver). Do you have the same issue when using -mkernel -Os ? (-Os on Apple's gcc is mostly -O2 with a bit more emphasis on code size) The code is vanilla C++ without anything fancy—no virtual functions even. There are no warnings about temporarys being used, so I have no clue what is causing the stack usage. It's a huge function with a lot ofswitch statements and for loops, but not a lot of function calls, mostly just computes on arrays of data. My best guess is that GCC is trying to optimize the intermediate operations and temporary results by placing them on the stack. You say "not a lot of function calls". Can you disable inlining or throttle it down to check that it's not the cause of the bloat ? If so, -Os would help. Anybody have ideas on how to show where GCC is allocating things in the frame, and how to reduce the stack usage? It's hard to distill this to a single issue because the function is so large, but I am tempted to file a bug since GCC 4 optimizes things quite nicely on other platforms. This email sent to eric.gouriou(a)pobox.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: GCC stack size
by Ryan McGann 21 Feb '09

21 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Feb 20, 2009, at 10:07 PM, Eric Gouriou wrote: On Feb 20, 2009, at 4:15 PM, Ryan McGann wrote: Thanks, Ryan Thanks, Ryan _______________________________________________ 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… A couple weeks ago I asked about a machine-check panic I was getting. As it turns out, my suspicions were right about stack corruption. I disassembled a function in our kext and saw that for some reason, GCC's function prologue was allocating around 1660 bytes of stack (in release, debug was slightly better at 1140 bytes). On other platforms compiled with GCC (FreeBSD and many different Linux distros) the stack usage is near 110 bytes, but for some reason gcc on Mac OS X is allocating almost 4K. We are currently using -O3 because the code is pretty compute- bound, and on other platforms -O3 has a nice 5% boost compared to - O2. But changing it to -O2 doesn't even help, we have to go all the way to -O1 to get a usable stack of 400 bytes (still 4x larger than our Linux driver). What are your compile options, besides -O3 ? There's a couple, but most are-I and -isysroot. Here's the trimmed down (all -I s removed) command for the function that has the problem: g++ -W -Wall -Wcast-qual -Wcast-align -Wpointer-arith -Wsign-compare - Winline -Wunused -mmacosx-version-min=10.4 -Di386 -DDarwin - D__STDC_FORMAT_MACROS -fcheck-new -mkernel -Os -DNDEBUG -c -o BUILDTARGETS-RELEASE/Darwin-9.6.0-i386-Mac_OS_X-10.5.6/regexr.o regexr.cpp Only options of real significance is the -mkernel and -fcheck-new, neither of which AFAIK should cause (a ton) of stack usage. Also we have a userspace version of this library that uses the same options (except -mkernel), and it has stack sizes in the same neighborhood, so -mkernel is not the culprit here either. Do you have the same issue when using -mkernel -Os ? (-Os on Apple's gcc is mostly -O2 with a bit more emphasis on code size) The -Os option is better but still bad. All the options, including no optimization, produce a pretty large stack. -mkernel -O2, -mkernel -O3 produce a stack over 1600 bytes. -mkernel -O1 is better at 400 bytes, but that's still 4x larger than -O3 on FreeBSD. -Os produces a stack that's 1036 bytes, which is smaller than -O2 but way bigger than -O1. The code is vanilla C++ without anything fancy—no virtual functions even. There are no warnings about temporarys being used, so I have no clue what is causing the stack usage. It's a huge function with a lot ofswitch statements and for loops, but not a lot of function calls, mostly just computes on arrays of data. My best guess is that GCC is trying to optimize the intermediate operations and temporary results by placing them on the stack. You say "not a lot of function calls". Can you disable inlining or throttle it down to check that it's not the cause of the bloat ? If so, -Os would help. That's what I thought too—there is a lot of inlining, so I thought -Os would help, but in fact -Os seems to be only marginally better than -O2. This function is is kind of the "heart" of our code, so it can be called a lot, and sometimes recursively, so we are looking for something in the 100-200 byte range. All the variables have been put into a struct that is (OS)Malloc'd and the function was designed to be a leaf function (not many external function calls except for malloc/ free) to minimize stack usage. The best I can get is 400 bytes, and that's with -O1. For something that is basically just a lot of array/ pointer manipulation I don't understand where the space is going. We've used this library on Linksys switches without problem. My assembly language is pretty bad for x86, and this function is several pages of C[++] code, but taking a look through the assembly I found something strange—although the prologue moves the stack down 1000+ bytes, and the epilogue moves it up by the same, I didn't find any instructions that used anything beyond the 24th byte in the frame. It looks like the first couple of words on the stack are for the parameters to the function, and every time there's recursion, those words are retrieved from the stack to pass to the recurive call. I didn't see anything accessing a offset from the %esp except in the prologue and epilogue, where the esp was used for the subl/addl, and I don't see any pushl except in the prologue. So perhaps it's an alignment issue--but the default stack alignment should be 4 or 16 bytes, not 1600 bytes. Also of note: this problem occurs on PowerPC as well, though it's different (abnormally large) sizes for the stack, and it's not as bad. But our kext still panics on that platform too. Anybody have ideas on how to show where GCC is allocating things in the frame, and how to reduce the stack usage? It's hard to distill this to a single issue because the function is so large, but I am tempted to file a bug since GCC 4 optimizes things quite nicely on other platforms. This email sent to site_archiver(a)lists.apple.com

1 0

Re: GCC stack size
by Eric Gouriou 21 Feb '09

21 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Feb 20, 2009, at 4:15 PM, Ryan McGann wrote: What are your compile options, besides -O3 ? Do you have the same issue when using -mkernel -Os ? (-Os on Apple's gcc is mostly -O2 with a bit more emphasis on code size) Eric Thanks, Ryan _______________________________________________ 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/eric.gouriou%40pobox.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… A couple weeks ago I asked about a machine-check panic I was getting. As it turns out, my suspicions were right about stack corruption. I disassembled a function in our kext and saw that for some reason, GCC's function prologue was allocating around 1660 bytes of stack (in release, debug was slightly better at 1140 bytes). On other platforms compiled with GCC (FreeBSD and many different Linux distros) the stack usage is near 110 bytes, but for some reason gcc on Mac OS X is allocating almost 4K. We are currently using -O3 because the code is pretty compute-bound, and on other platforms -O3 has a nice 5% boost compared to -O2. But changing it to -O2 doesn't even help, we have to go all the way to - O1 to get a usable stack of 400 bytes (still 4x larger than our Linux driver). The code is vanilla C++ without anything fancy—no virtual functions even. There are no warnings about temporarys being used, so I have no clue what is causing the stack usage. It's a huge function with a lot ofswitch statements and for loops, but not a lot of function calls, mostly just computes on arrays of data. My best guess is that GCC is trying to optimize the intermediate operations and temporary results by placing them on the stack. You say "not a lot of function calls". Can you disable inlining or throttle it down to check that it's not the cause of the bloat ? If so, -Os would help. Anybody have ideas on how to show where GCC is allocating things in the frame, and how to reduce the stack usage? It's hard to distill this to a single issue because the function is so large, but I am tempted to file a bug since GCC 4 optimizes things quite nicely on other platforms. This email sent to eric.gouriou(a)pobox.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: ACL Inheritance?
by Terry Lambert 21 Feb '09

21 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi all! The answer is "no". -- 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 20, 2009, at 3:32 PM, Benjamin Huntsman wrote: This may not be the right list, but perhaps someone could point me in the right direction regarding ACL's on Mac OS X... I've got an XServe running 10.4, with an attached Xserve RAID. The raid array is running XSan, and mounted as a single volume under / Volumes. The Xserve is joined to an Active Directory domain, which it uses for authentication. The folders at the root of the XSan volume are configured as SMB shares, so that Windows clients can access them. So here's the catch... we want to have a certain group in the Active Directory domain control access to one of the folders on the Xsan volume. When the server was set up, they were using UNIX permissions (user, group, others) to configure access, which became problematic as more and more users were added to the system. Switching to ACL's after the fact though, hasn't worked very well. The Active Directory group is added in Workgroup Manager to the folder, and set to propagate, but it doesn't do so to all subfolders, especially those that were present before the change. I set up a test volume on a dmg to experiment via the command line, and found that if you set an ACL with inheritance on a folder that ALREADY contains a subfolder, the subfolder won't automatically inherit the ACL from it's parent, but all subsequently created folders or files will. So my question is, is there a way, via the command line or otherwise, to essentially tell a folder or file to "re-inherit" it's ACL list from it's parent? I can do 'chmod -R +a "<acl>" folder', but that's not what we're after... Inheritance happens at create time. Even if you rename something into a directory, it won't do it (since the file is not being created). You can archive and restore it, and the restor will create the file/ directory. This assumes that the archiving program desn't know about ACLs (and save off the old ones without inherited values, and restore them - without inherited values. This email sent to site_archiver(a)lists.apple.com

1 0

Re: GCC stack size
by Ryan McGann 21 Feb '09

21 Feb '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Feb 20, 2009, at 4:54 PM, Jan Brittenson wrote: These are shorthand to turn on/off the various optimization options. Ryan McGann wrote: We are currently using -O3 because the code is pretty compute- bound, and on other platforms -O3 has a nice 5% boost compared to - O2. But changing it to -O2 doesn't even help, we have to go all the way to -O1 to get a usable stack of 400 bytes (still 4x larger than our Linux driver). If I were you I'd find out what exactly they expand to, and which of the options cause the stack bloat. Then I'd explicitly turn off that, or those, optimizations. It may take some guesswork and experimentation with the a la carte options. You might also be able to find a way to reorder the code to work around. For instance, if it's caused by -fstack-realign, then try compiling with -O3 -fno-stack-realign. The difference from your Linux driver is probably just a function of gcc version used. When your Linux build environment catches up you'll likely find you have the foot print issues there as well. I should have mentioned that all the drivers use g++ 4.0.1 to compile. For whatever reason, on Linux and FreeBSD, -O3 expands to something very different on Mac OS X. I guess the divide & conquer approach is the one I'll take to figure out the offending compiler option(s) but I was hoping somebody had a smoking gun, since -O3 expands to about 25 options. Ryan _______________________________________________ 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