Date: Sun, 29 Oct 2006 00:32:52 -0600 From: Scott Long <scottl@samsco.org> To: Matthew Jacob <lydianconcepts@gmail.com> Cc: freebsd-scsi@freebsd.org Subject: Re: CAM_NEW_TRAN Message-ID: <45444B14.8000102@samsco.org> In-Reply-To: <7579f7fb0610281840j2ee74f5av18239d4c9c702460@mail.gmail.com> References: <E1GdoR8-0007SG-Re@cs1.cs.huji.ac.il> <7579f7fb0610281836t4f13efcfm15c1b238cff96a7@mail.gmail.com> <7579f7fb0610281840j2ee74f5av18239d4c9c702460@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote: >> >> iSCSI: >> I don't know - I haven't played with your iSCSI driver yet. I would >> actually expect things to be substantially easier as you can then make >> iSCSI a transport protocol and do transport specific things within it >> which are awkward otherwise. > > > Incomplete thought: to a first approximation it shouldn't really > affect you much at all. Most of the 'driver' changes are things just > put into slightly different structures and called something a bit > different. > > The notion then would be to start taking this further and doing more > and more useful things with it. > > For example, camlib/camcontrol would then be taught about the > different transport types and could report WWPNs and whatnot for FC > and whatever that ridiculous 511 byte UUID there is for iSCSI. > Everyone I know who uses FreeBSD with Fibre Channel and target mode > has to hack things to get that information. Making changes that forces application changes (xmcd, cdparanoia) is going to be hard to swallow. If they just need a recompile, that's a lot better. Having a shim for binary compatibility would be the best. All depends on how much work you want to put into it. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45444B14.8000102>