haad wrote:
On Mon, Nov 9, 2009 at 11:25 PM, Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost> wrote:Manuel Bouyer wrote:On Mon, Nov 09, 2009 at 06:48:21PM +0000, Hugo Silva wrote:[...] dmesg: xbdback backend/vbd/1/1: can't DIOCGPART device 0xa901: 12 // <------- ?OK, that's the problem. Maybe xbdback should try DIOCGDISKINFO in this case. Sorry, I can't look at a patch right now ...proplib(3) things are obscure to me. IIUC, the VOP_IOCTL() for the devmapper associated to DIOCGDISKINFO returns an externalized form of the disk-info prop_dictionary_t, namely, a struct plistref. I can't manage to find how I can get the "block-count" key out of it. I would need some kind of prop_dictionary_internalize, to turn this externalized form into a proplib object. Attached is an ugly patch, untested. Caution, applying it will render all disklabel-based partitions unsuitable for xbd backend as is, it replaces the DIOCGPART ioctl() with the DIOCGDISKINFO one. It is likely that it will panic() the dom0 as well upon domU create.I think that we need to replace DIOCGWEDGEINFO with DIOCGDISKINFO. This way we will have old DIOCGPART working and all new disk/pseudo-disk devices have to support DIOCGDISKINFO.
I've been digging through the code til now. The closest I got to getting the disk size was dumping the dictionary I got from prop_dictionary_recv_ioctl(fd_of_vg00-lv0, DIOCGDISKINFO, &disk_dict) to a file and manually inspecting it.
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
<plist version="1.0">
<dict>
<key>geometry</key>
<dict>
<key>cylinders-per-unit</key>
<integer>0xec93d</integer>
<key>sector-size</key>
<integer>0x200</integer>
<key>sectors-per-track</key>
<integer>0x3f</integer>
<key>sectors-per-unit</key>
<integer>0x3a386030</integer>
<key>tracks-per-cylinder</key>
<integer>0x10</integer>
</dict>
<key>type</key>
<string>ESDI</string>
</dict>
</plist>
0x3a386030 == 976773168, /netbsd: wd0: 465 GB, 969021 cyl, 16 head, 63
sec, 512 bytes/sect x 976773168 sectors
I was now trying to find a way to change xbdback_xenbus.c to use this value (while still not being sure if it should be given in sectors..), however I couldn't use prop_dictionary_get properly to retrieve anything from disk_dict; some silly mistake somewhere, for sure.
I'm not even sure if could use prop_dictionary_get or even prop_dictionary_recv_ioctl in the context of our discussion, whether I should be using anything more than VOP_IOCTL (prop_dictionary_recv_ioctl takes a fd and I think I need a vnode in xbdback_xenbus.c)
It's (quite) late now and I will be away from this machine for a week, so Iwon't be able to test patches til then. If there aren't none by the time I'm back I fully intend to continue looking at this, however slow my lack of programming experience and debugging skills make the process.