May 2004 - Darwin-kernel - lists.apple.com

Re: Is there a file system flag for >2GB file support?
by Quinn 13 May '04

13 May '04

At 17:21 +0100 13/5/04, Quinn wrote: As a rule I recommend against that approach. I could swear that DTS published a Q&A entitled "Test what you ship" that explains why this is a bad idea, but I can't, for the life of me, find it. And lo, I found it... <http://developer.apple.com/qa/ov/ov01.html> It's a fun story. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Is there a file system flag for >2GB file support?
by Brian Bergstrand 13 May '04

13 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Quinn, Bugs filed: 3653745: extend getattrlist() to return max file size 3653754: extend getattrlist() to return filesystem UUID I know you can't say, but hopefully these can be implemented in the next major release. On May 13, 2004, at 11:21 AM, Quinn wrote: > > At 11:54 -0500 11/5/04, Brian Bergstrand wrote: >> How about an extension to getattrlist()? Another VOL_CAP? >> >> Perhaps VOL_CAP_FMT_LARGE_FILES? > > Well, I'd prefer a new attribute that returns the maximum file size > for the file system, that way file systems can be specific about what > they support. > >> I'd also like to see getattrlist() extended so the FS UUID can be >> accessed. > > Indeed. Please file a bug requesting this and send me the bug number. > > Brian Bergstrand <http://www.bergstrand.org/brian/>, AIM: triryche206 PGP Key: <http://www.bergstrand.org/brian/misc/public_key.txt> For the skeptic there remains only one consolation: if there should be such a thing as superhuman law it is administered with subhuman inefficiency. - Eric Ambler -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQKO6B3nR2Fu2x7aiEQL2eQCfaFJb5jRe5M/sGXzoOmQd7CDu5NkAni8d VghLNzAnc09IZTHVMs6xn+fZ =uMV/ -----END PGP SIGNATURE----- _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Is there a file system flag for >2GB file support?
by Quinn 13 May '04

13 May '04

At 15:53 +1000 11/5/04, Sam Vaughan wrote: If FCP were testing the bSupports2TBFiles bit, which VOP/VFS interface would the Carbon File Manager be using to ask us the answer? AFAIK that would be a new API. I'd like to put the code in now so that it will all just work when FCP/CFM are fixed. As a rule I recommend against that approach. I could swear that DTS published a Q&A entitled "Test what you ship" that explains why this is a bad idea, but I can't, for the life of me, find it. At 11:54 -0500 11/5/04, Brian Bergstrand wrote: How about an extension to getattrlist()? Another VOL_CAP? Perhaps VOL_CAP_FMT_LARGE_FILES? Well, I'd prefer a new attribute that returns the maximum file size for the file system, that way file systems can be specific about what they support. I'd also like to see getattrlist() extended so the FS UUID can be accessed. Indeed. Please file a bug requesting this and send me the bug number. <http://developer.apple.com/bugreporter/> Note that we already have a mechanism for associating volumes with 64-bit unique identifiers (vsdbutil) but there's no nice way for the volume format to get involved in the process. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Is there a file system flag for >2GB file support?
by Brian Bergstrand 11 May '04

11 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How about an extension to getattrlist()? Another VOL_CAP? Perhaps VOL_CAP_FMT_LARGE_FILES? I'd also like to see getattrlist() extended so the FS UUID can be accessed. On May 11, 2004, at 12:53 AM, Sam Vaughan wrote: > d'Oh! > > 3650132. > > If FCP were testing the bSupports2TBFiles bit, which VOP/VFS interface > would the Carbon File Manager be using to ask us the answer? I'd like > to put the code in now so that it will all just work when FCP/CFM are > fixed. > > Thanks Quinn, > > Sam > > On 11/05/2004, at 3:00 PM, darwin-kernel-request(a)lists.apple.com wrote: > >> Hmmm, I think that there are least two issues here. For a start, FCP >> (or whatever underlies it) should determine whether a volume supports >> large files by testing the bSupports2TBFiles bit in the >> vMExtendedAttributes field of the GetVolParmsInfoBuffer returned by >> the Carbon File Manager routine PBHGetVolParmsSync. However, it >> doesn't look like it's doing this (because of the next point). I'd >> consider that a bug. >> >> Second, it seems that the Carbon File Manager sets this flag based on >> a simple volume identifier check. If the volume is original HFS, it >> clears the flag, otherwise it sets it. This is a bug IMHO. The >> Carbon File Manager should not contain hard-wired special cases for >> particular file systems. >> >> You know the drill... >> >> <http://developer.apple.com/bugreporter/> > Brian Bergstrand <http://www.bergstrand.org/brian/>, AIM: triryche206 PGP Key: <http://www.bergstrand.org/brian/misc/public_key.txt> To know recursion, you must first know recursion. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQKD3MnnR2Fu2x7aiEQKhxgCfZevjdLjGbvFOCwmYWninp4HFWmQAoOvB rLH8wHqRw5QdP1NMCoL5x7kE =uaLq -----END PGP SIGNATURE----- _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Is there a file system flag for >2GB file support?
by Sam Vaughan 11 May '04

11 May '04

d'Oh! 3650132. If FCP were testing the bSupports2TBFiles bit, which VOP/VFS interface would the Carbon File Manager be using to ask us the answer? I'd like to put the code in now so that it will all just work when FCP/CFM are fixed. Thanks Quinn, Sam On 11/05/2004, at 3:00 PM, darwin-kernel-request(a)lists.apple.com wrote: Hmmm, I think that there are least two issues here. For a start, FCP (or whatever underlies it) should determine whether a volume supports large files by testing the bSupports2TBFiles bit in the vMExtendedAttributes field of the GetVolParmsInfoBuffer returned by the Carbon File Manager routine PBHGetVolParmsSync. However, it doesn't look like it's doing this (because of the next point). I'd consider that a bug. Second, it seems that the Carbon File Manager sets this flag based on a simple volume identifier check. If the volume is original HFS, it clears the flag, otherwise it sets it. This is a bug IMHO. The Carbon File Manager should not contain hard-wired special cases for particular file systems. You know the drill... <http://developer.apple.com/bugreporter/> Please send me the bug numbers. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Is there a file system flag for >2GB file support?
by Quinn 10 May '04

10 May '04

At 17:21 +1000 10/5/04, Sam Vaughan wrote: Does anyone know of a flag we should be setting in our statfs or getattrlist to tell Final Cut Pro that it doesn't need to break up its exported files into 2GB chunks? Hmmm, I think that there are least two issues here. For a start, FCP (or whatever underlies it) should determine whether a volume supports large files by testing the bSupports2TBFiles bit in the vMExtendedAttributes field of the GetVolParmsInfoBuffer returned by the Carbon File Manager routine PBHGetVolParmsSync. However, it doesn't look like it's doing this (because of the next point). I'd consider that a bug. Second, it seems that the Carbon File Manager sets this flag based on a simple volume identifier check. If the volume is original HFS, it clears the flag, otherwise it sets it. This is a bug IMHO. The Carbon File Manager should not contain hard-wired special cases for particular file systems. You know the drill... <http://developer.apple.com/bugreporter/> Please send me the bug numbers. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Is there a file system flag for >2GB file support?
by Sam Vaughan 10 May '04

10 May '04

It's a toss-up as to whether this is a Darwin kernel or Final Cut Pro question, but here goes: Does anyone know of a flag we should be setting in our statfs or getattrlist to tell Final Cut Pro that it doesn't need to break up its exported files into 2GB chunks? Exporting a large movie to HFS+ results in a single file. On CXFS it results in a series of 2GB chunks. We've scanned the headers for appropriate flags but haven't seen any. Maybe Final Cut Pro hard codes the IDs of known-safe file systems? I hope not... Thanks, Sam _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Using sysctl inside kernel
by Matthew Jaffa 03 May '04

03 May '04

Hi, I know no one really encourages using sysctl inside the kernel, but that is what I am trying, I have read kern_sysctl.c, and kern_newsysctl.c looking into the kern_sysctl and kern_procargs methods. And read kern_execv.c something like that, to know what happens at process creation time. In my KEXT I have successfully done kern_sysctl with mibs of mib[0] = KERN_PROCARGS2; mib[1] = the_process_id; And the sysctl has returned successfully, but it appears that I get garbage back, I know that is grabbing something new, because I set the char * value : pathss[0] = '4'; pathss[1] = '\0'; And then after the call they change, Anyone who knows about this stuff, know how to take what I return and give me the correct procargs for that process, kern_procargs I see takes the virtual memory from the pid to find the procargs for that process stored on its user stack. And copies it into kernel space. So I am using kern_sysctl -> which then calls kern_procargs2 and then calls kern_procargsx which is where all the virtual memory copying from user space to kernel space happens. I know procargs2 is new to panther and I am using this under Panther only, If there is anyone out there that is willing to help, please let me know. I know I have gotten messages before that you can't be sure of getting the path, but if I read execv correctly from the xnu sources, it is storing the procs arguments on the top, or bottom, of the stack depending on how it is interpreted. I am ok if they move the application around, I still want what is stored on the stack at the time the process was created. I have successfully done this in userspace, using some code I got from Panther's ps command line that lists all the processes, I then took that code and modified it for the kernel, and after much work finally got it to succeed, but lacking correct results. Maybe what I am getting back from my kern_sysctl call is right but don't know how to format or interpret the resulting data back, it says it succeeded, but I doubt it is not working since I printed out every character from the resulting char * back, and no path like part was ever printed out. Thanks, Matt _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Darwin 7.1
by Nicolas Bock 03 May '04

03 May '04

On May 3, 2004, at 5:36 AM, Roger Midmore wrote: I want to build the new darwin kernel but i need to install the package kext_tools first. However there is no make file includeded for this project and I was wondering how other people got it installed. Roger, I couldn't figure this out myself either. As per suggestion by someone else I downloaded a darwin installation image and copied the program /usr/local/bin/kextsymboltool from the image into /usr/local/bin in my OS X installation. You can find the image at http://opendarwin.org/en/news.php#30 nick _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Darwin 7.1
by Roger Midmore 03 May '04

03 May '04

I want to build the new darwin kernel but i need to install the package kext_tools first. However there is no make file includeded for this project and I was wondering how other people got it installed. roger _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0