On 09/29/2009 04:19 PM, Mike Christie wrote: > On 09/29/2009 02:03 PM, Joe Eykholt wrote: >> Joe Eykholt wrote: >>> The kernel no longer has symlinks where libhbalinux expected them. >>> I'm not sure which kernel version this was written for. >>> >>> Don't expect "/sys/class/fc_hosts/<hostx>" to be a symlink. >>> Change to look for the symlink "/sys/class/fc_hosts/<hostx>/device". >>> >>> Don't expect the strings "/net/" or "/virtual/net/" to be in the symlink. >>> >>> To find the real interface for a vlan, compare the iflink and ifindex. >>> If they are not the same, look for the interface who's ifindex matches >>> the iflink of the vlan. >>> >>> This is RFC until someone can test it against older kernels that might >>> need to be supported. This works on today's fcoe-next kernel with a >>> mix of fcoe and fnic. I also tried it with a mix of fcoe and >>> qla2xxx (without a vendor library for the latter, it is ignored). >> I tried this under RHEL5.4 and it works, although I wasn't able to test with >> VLANs. >> >> There is another somewhat-related issue that I ran across on RHEL5.4. >> The device passed to scsi_add_host() is from netdev->class_dev.dev->parent. >> I don't understand why that parent deref is there. For the enic driver, >> the parent is a bridge, so fcoeadm -i shows the bridge device. For ixgbe, >> I assume fcoeadm -i works correctly although I don't have a RHEL setup with >> ixgbe just now. So, is enic doing something wrong or is fcoe wrong? >> It seems to me that fcoe is wrong, but the parent deref must be there for >> a reason. Is the device supposed to be a net device instead of a pci device, >> such that the parent is usually the pci device? >> > > scsi_add_host wants the device with dma settings/restrictions, so later > in functions like scsi_alloc_queue/__scsi_alloc_queue it can set the > block/queue segment/dma/scatterlist settings with it. Does the netdev > device have that? Maybe for upstream it does and for RHEL 5 it did not. > I think for RHEL 5.4, there was a difference between what upstream > netdev device and what RHEL's netdev device have/are, because of the
I mean I think (thought at the time) that upstream's netdev device pointed to the pci device, but in RHEL 5.4 the netdev->class_dev.dev device was more of a dummy network layer device struct so the deref to the parent got me to the pci device I wanted. I do not 100% remember though. > move away from class_devices, or for RHEL 5 I just screwed up. > _______________________________________________ > devel mailing list > [email protected] > http://www.open-fcoe.org/mailman/listinfo/devel _______________________________________________ devel mailing list [email protected] http://www.open-fcoe.org/mailman/listinfo/devel
