On Tue, Aug 14, 2007 at 02:40:47PM -0400, Nils Nieuwejaar wrote: > On Tue 08/14/07 at 10:27 AM, [EMAIL PROTECTED] wrote: > > > > > For example, there are two major variants of realtek 8139. The main > > > 8139 family, which is pretty "sucky", and the 8139C+. The 8139C+ > > > supports pretty much everything that the 8169 does (including vlan > > > tagging, hardware checksum offload, descriptor based DMA, etc.) > > > > > > The way to tell the difference is to look at a revision register that > > > isn't part of the normal PCI configuration space. > > > > Wouldn't the right solution be to merge two drivers? > > I'm wrestling with something similar right now, trying to implement > paravirtualized disk drivers for a fully virtualized Xen domain. > > Xen presents each disk device to a domain twice: once as an emulated PCI > device and once as a paravirtualized front end device. This means the same > disk shows up in two places in the device tree, with two unrelated names. > I need to find some way for the PV disk driver to prevent the ata disk > driver from attaching to the same devices. > > I'm not a device guy, so I don't know how common this problem is, or > whether the 'quirks' idea would be generally helpful, but it does sound > like it might work for me. >
this problem sounds different from the one garrett is looking at. garrett is looking at two different devices with the same device id. in your case you have two different devices (with different device ids) that are actually the same underlying device. your case sounds more like dealing with a multipath device. your case actually seems to map to an mpxio based solution where you have a single disk nodes with two paths: ata and pv. the vhci node would of course always prefer the pv path over the ata path for performance reasons. that said, using an mpxio solution in the real world provides redundancy that is probably not needed (or is even pointless) in a virtualized environment. there for it seems the other option would be to have the two disk nexus drivers be aware of eachother and to have the ata driver refust to map it's children when it knows that the pv driver is available. yuck. ed _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
