July 2005 - Darwin-kernel - lists.apple.com

Re: Where is sysent structure hiding in 10.4.2?
by Quinn 22 Jul '05

22 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, 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 15:03 +0000 22/7/05, rcircle(a)speakeasy.net wrote: I have an application that runs under Mac OSX 10.3 but when I rebuild it under 10.4 and load with kextload -t it does not find _sysent. Any ideas. The system call dispatch table is no longer exported by the kernel. If you can describe what you're trying to do, I may be able to suggest a workaround. This email sent to site_archiver(a)lists.apple.com

1 0

Where is sysent structure hiding in 10.4.2?
by rcircle＠speakeasy.net 22 Jul '05

22 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Importance: Normal Sensitivity: Normal I have an application that runs under Mac OSX 10.3 but when I rebuild it under 10.4 and load with kextload -t it does not find _sysent. Any ideas. _______________________________________________ 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

Write of filter scheme driver
by Mekhala Patil 22 Jul '05

22 Jul '05

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

Re: Finding Blocks occupied by the file on the volume
by Peter Lovell 21 Jul '05

21 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 21, 2005, at 6:48 PM, Terry Lambert wrote: On Jul 21, 2005, at 7:03 AM, Shawn Erickson wrote: On Jul 21, 2005, at 3:23 AM, santosh katvate wrote: hi mike If i keep the handle of the file open then i don't think that filesystem will try to recycle the blocks corresponding to file as long as the handle is open This is a very unsafe assumption. -Shawn Hi Terry, I'd like to extend a very big "thank you" for your detailed explanation. Regards.....Peter _______________________________________________ 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 understand the persistence of the question; Windows supports an IFS API mechanism for getting this information. <snip> In MacOS X, there is no such contract on open or locked files (just as Shawn says, here). This is exactly the sort of detail which helps keep observant developers away from disaster. Issues such as this can't generally be forseen and covered in headers or dev notes, so having someone crisply specify the contract is great. Although this is not my specific area of interest, you have my thanks for taking the time for this explanation. I do hope you your manager (s) take notice as well. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Finding Blocks occupied by the file on the volume
by Terry Lambert 21 Jul '05

21 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com hi mike If i keep the handle of the file open then i don't think that filesystem will try to recycle the blocks corresponding to file as long as the handle is open -- Terry _______________________________________________ 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.… On Jul 21, 2005, at 7:03 AM, Shawn Erickson wrote: On Jul 21, 2005, at 3:23 AM, santosh katvate wrote: This is a very unsafe assumption. For example in that same document you are looking at review the section on "Hot Files" [1]. If the volume is mounted then the HFS+ file system code owns that file system, it can do whatever it wants with blocks of data on disk totally independent of what system level calls are made. You really cannot make any safe assumptions about how blocks will exist on disk as long as a file system driver owns the volume and you don't really have a good API that will let you get at that information from the file system driver itself, that I know of at least. -Shawn I understand the persistence of the question; Windows supports an IFS API mechanism for getting this information. For it to work there, you basically have to assert a level 3 volume lock, and a level 0 volume lock, lock the file, and get the information using a (sparsely documented) FS_Ioctl16Drive via INT 21 API. The primary reason people use this interface on Windows is, as Quinn suspected such an interface might be used, to do direct I/O to the disk, bypassing the IFS. In the general case, it's only ever done by Windows itself, in order to support swap files for use by the OS. By avoiding the IFS layer, they avoid the physical to logical device translation, and the logical device to IFS layout translation, which is expensive, partly because the way the API is laid out, and partly because of the disk structure. The API was originally invented because doing random I/O to FAT FSs in all their variants required traversing the FAT chain from the start to whatever offset where you wanted to do the I/O at. By asking for the block map up front, they converted this from an O(N!) operation for simple sequential I/O requiring disk I/O to an O(?) operation in memory (even if ? := N!, it's faster). This works because the IFS makes a contract with the IFSMgr to guarantee that a locked file will not have its blocks relocated on the disk. IFSMgr, at least in the past, punted in this area by not supporting swapping on removable media (I found this out in 1996, while working at another company, when I tried to install Windows 95 on a JAZ disk, and had strange error). In MacOS X, there is no such contract on open or locked files (just as Shawn says, here). In fact, there are FS's, specifically, some FS's backed by flash devices are designed to evenly distribute write cycles over the flash device to increase lifetime, given a finite number of write cycles per cell, where this is *not* true and *cannot* EVER be true and still achieve the FS design goals. In other words, whatever you do with an interface like this, it will probably break in the future as FS technology continues to evolve past your assumptions, if not immediately from some third party VFS. Supporting this yourself will mean taking the file system (or fsck) source code, and looking at how the physical disk is laid out, assuming you can get at the disk in the first place (i.e. it's not mounted so the raw device can be opened). Even then, we don't promise to not change things out from under you, and third party VFS's *certainly* make no such promise. You might be better off supplying your own VFS based on the FS you are trying to do this for, and adding your own entry-point hooks to additional functions via VNOP_IOCTL to do the work of locking/ unlocking/getting block information under the covers. I'd like to *strongly* discourage you from going this route; if you are going to go anywhere near it, you might as well make your VNOP_IOCTL do the work right then, instead of externalizing it via a new API that you will have to update each time a Software Update happens to bump the minor version number. This email sent to site_archiver(a)lists.apple.com

1 0

Re: current_task(), struct proc...
by Mike Smith 21 Jul '05

21 Jul '05

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

Re: Finding Blocks occupied by the file on the volume
by Shawn Erickson 21 Jul '05

21 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 21, 2005, at 3:23 AM, santosh katvate wrote: hi mike If i keep the handle of the file open then i don't think that filesystem will try to recycle the blocks corresponding to file as long as the handle is open -Shawn _______________________________________________ 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 is a very unsafe assumption. For example in that same document you are looking at review the section on "Hot Files" [1]. If the volume is mounted then the HFS+ file system code owns that file system, it can do whatever it wants with blocks of data on disk totally independent of what system level calls are made. You really cannot make any safe assumptions about how blocks will exist on disk as long as a file system driver owns the volume and you don't really have a good API that will let you get at that information from the file system driver itself, that I know of at least. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Finding Blocks occupied by the file on the volume
by santosh katvate 21 Jul '05

21 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o4631aqrDGoxgweEnP5s3mvrrWZlAqUxL8PixGVOkW7pfTZG3ru4Fp0tMPV5u2HpkZ8UBWa7eQG4o4QpVIrOCFyO9pbpVu4D13bfhLOObfjbJxWsmHkARlA5MdnvJbgZBySGWypfj7iU3BOT11AEMe1JCCJxSCN/h69fB1uW+ws= hi mike If i keep the handle of the file open then i don't think that filesystem will try to recycle the blocks corresponding to file as long as the handle is open According to http://developer.apple.com/technotes/tn/tn1150.html , the catalog file stores the first 8 extents: HFS Plus maintains information about the contents of a file using the HFSPlusForkData structure. Two such structures -- one for the resource and one for the data fork -- are stored in the catalog record for each user file. In addition, the volume header contains a fork data structure for each special file. Do anyone have any idea of how to obtain the catalog record corresponding to file? what are the api's or function to obtain this. thanks santosh k On 7/21/05, santosh katvate <santosh.nk(a)gmail.com> wrote: > hi mike > > If i keep the handle of the file open then i don't think that > filesystem will try to recycle the blocks corresponding to file as > long as the handle is open > > > According to http://developer.apple.com/technotes/tn/tn1150.html , the > catalog file stores the first 8 extents: > HFS Plus maintains information about the contents of a file using the > HFSPlusForkData structure. Two such structures -- one for the resource > and one for the data fork -- are stored in the catalog record for each > user file. In addition, the volume header contains a fork data > structure for each special file. > > Do anyone have any idea of how to obtain the catalog record > corresponding to file? > what are the api's or function to obtain this. > > > thanks > santosh k > -- Life is Small and Lots of Things to Learn Lets Share the Knowledge _______________________________________________ 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

current_task(), struct proc...
by Herb Petschauer 21 Jul '05

21 Jul '05

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=TYdJnueebuoHkVTu+liqb6PNKcvfghBI9LN6mGjMSo6sLwn9u9VeLE9qPwqgemKzYmliZ35Htkbv7fdqChQq6/gLPTJ5FYNQsB6jnwKST+cxT5cgn2eyPxVMVcZldKPRb5pksBT3c0WOH8PjNDwILEhTtnpO1XHX4IV9K1/JnNs= This is more of a sanity check (I've done the code check on this under Panther and a quick look at the Darwin source). I have a character device (struct cdevsw) that is being installed via cdevsw_add() (etc.). The ioctl works fine, no problems here. Under some circumstances, memory mapping is performed (say user to kernel). Under Panther the task_t id is gotten directly from the struct proc parameter. Under Tiger, I'm not seeing an API to extract the task id from the proc struct so I thought that current_task() would be a safe bet. Under Panther, I can see that in this scenario, current_task() == p->task. I can't see why that wouldn't always be true (in this scenario, I need to do more code reading for a better blanket statement and it's not really important at the moment). Is it safe to just port my ioctl callback routine to use current_task() for both Tiger and Panther? Thanks! Cheers, H. _______________________________________________ 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

Darwin Kernel for OpenSolaris System on X86 System
by Gottfried Zojer 20 Jul '05

20 Jul '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello to all, Maybe my posting wasnt correct.That what I meant was if somebody thought about merging a DarwinOS Kernel with a OpenSolaris X86 System. Means using the Darwin Kernel but using on top of it a OpenSolaris system. I m curios about the possible interfaces of such a system. Again thanks for any feedback Rgds Gottfried _______________________________________________ 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