Re: About partition scheme.
Re: About partition scheme.
- Subject: Re: About partition scheme.
- From: "Flost.D.Li" <email@hidden>
- Date: Thu, 05 Jul 2012 10:25:42 +0800
THanks phil,
在 2012-7-4，下午9:24， Phil Jordan 写道：
> On Wed, Jul 4, 2012 at 2:54 PM, Li Flost.Dexiong <email@hidden> wrote:
>>
>> 在 2012-7-4，下午8:34， Phil Jordan 写道：
>>
>>> On Wed, Jul 4, 2012 at 2:17 PM, Li Flost.Dexiong <email@hidden> 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.
[Flost] so the disk3 was generated by disk2s2. Can you control the inter activation with disk2s2?
>
> 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/KEXTConcept/KEXTConceptDebugger/debug_tutorial.html
[Flost]: Yes, I'd read this document before, but last time when i have two machine to study this, I find that only the system got panic, than the debug machine could connect to the test machine, and show the stack, but this does not make much help than I use the panic file to decode the stack.
May be I could read the article more carefully. Also, I will reference the following article to learn about firewire kprintf.
>
> 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/KernelProgramming/build/build.html#//apple_ref/doc/uid/TP30000905-CH221-BABDGEGF
>
> 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
Best regards,
Flost.D.Li
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden