On Wed, Jul 4, 2012 at 2:54 PM, Li Flost.Dexiong <havefan2012@gmail.com> wrote:

在 2012-7-4，下午8:34， Phil Jordan 写道：

...

On Wed, Jul 4, 2012 at 2:17 PM, Li Flost.Dexiong <havefan2012@gmail.com> wrote:

...

[Flost]: I had once try to init my newMedia using true as the "isWhole" argument. but this will cause the system panic.

I've successfully written drivers which pass true for the isWhole argument. It works. [Flost] Does your device match your driver still show that #0 and #1 on one disk?

My driver actually matches on a specific partition type, so it looks something like this (disk2 is the "real" disk): /dev/disk2 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *160.0 GB disk2 1: EFI 209.7 MB disk2s1 2: E2A2381C-BE82-4CA7-B0D4-1B9F99BC285D 143.2 GB disk2s2 3: Apple_Boot Booter 268.4 MB disk2s3 /dev/disk3 #: TYPE NAME SIZE IDENTIFIER 0: Apple_HFS Lion *143.2 GB disk3 The driver matches on the special partition type with the GUID, in this case, disk2s2, and creates a "whole" IOMedia object, in this case disk3. There's nothing stopping you from matching on a whole disk (disk2) AND creating a whole disk (disk3). Normally, in your probe() and start() you would read a small piece of data from the start or end of the provider, and check that a special signature is present, to make sure this really is a disk that belongs to your driver. The child IOMedia device would then be slightly smaller than the provider and not cover that signature. That way, when matching happens for your new media device (disk3), although your probe() will be called again for this new device, it can't find the signature and probe() will fail. This then lets other drivers carry on matching. Examples of this are all the usual partition schemes: if you create only one partition with the maximum possible size, it won't cover the whole disk, but instead be slightly smaller, as the rest of the space is taken up by the partition table.

...

The panic probably doesn't happen on line 565 itself. I suggest using 2-machine debugging and synchronous kprintf logging. It really helps. [Flost]: Does this 2-mahines debugging method enable a runtime debugging? If yes, what can I refer to?

Yes, it's not quite as powerful as user-space debugging, but you can set breakpoints, inspect data, etc. It's briefly explained here: https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KEX... You can find more details on it elsewhere on the web and in OSX kernel books, and in the archives of this mailing list. For firewire or serial port kprintf, set the relevant bit in the debug setting of the kernel's boot-args: http://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/Kern... For firewire kprintf, run the fwkpfv terminal utility on the other machine (the other machine must not be using the firewire port for anything other than kernel debugging). I usually give it a big buffer, e.g. fwkpfv --buffer=5000000 to avoid overruns. For serial port kprintf (only works on old XServes with a serial port, or virtual machines with a virtual serial port) you just log the raw data on the other side of the serial cable.

...

You can't just "get rid of" disk1 as that's not generated in your code, and is in fact the provider to your filter scheme. You NEED it to exist. [Flost]: yes, I'd think about this before. but a saw that the disk labeled by Xsan was shown as below: /dev/disk9 #: TYPE NAME SIZE IDENTIFIER 0: Apple_Xsan_Component *5.4 GB disk9

It didn't show the two # . how does this to be understood?

I don't know where the Xsan stuff is coming from, but this is basically an unpartitioned, whole disk (disk9). phil _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com