On Tue, Dec 07, 2010 at 05:40:27PM +0200, Nir Muchtar wrote: > I understand. still, I prefer staying focused on the primary goal and > complete the patches before looking into this, So the solution for now > is to just skip on device name and obtain them from userspace using the > net devices and /sys/class. I might return to this once the first > patches are accepted.
This doesn't really work if the IB netdevice is part of a bond, and it won't work at all once Sean is done adding AF_GID. Churning the userspace ABI is a really bad idea, if something is hard to do, then fine. But this isn't.. > What I mean is that I will supply the maximum flexibility by supporting > arbitrary netlink messages and attributes. This will support your > suggested schema as well as any changes we'll agree upon. My current > plans are for RDMA CM exports and not QP table exports but this should > be next in line. Do you have an idea what this will look like? > > You shouldn't be attempting to dump the structure in one go while > > holding a lock, you need to try best-efforts to dump it by keeping > > some kind of current position value. > > > > inet_diag seems to use a pretty simple scheme where it just records > > the hash bucket and count into the chain. Not sure what happens if > > things are erased - looks like you'll get duplicates/misses? You could > > do the same by keeping track of the offset into the linked list. > > The thing is, there's no easy and clean way to retrieve the export when > using dump_start. I don't follow this comment, can you elaborate? This really needs to use the dump api, and I can't see any reason why it can't. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
