2012/12/10 Braun, David <David.Braun@xxxxxxx>: > Good catch but I don't think that's quite correct. To be accurate, the function list_first_entry(...) returns the first entry in the list or a pointer to the list head if empty. > > The return is LUN0 only because LUN0 is created automatically when the target is created. Yes. > The function list_first_entry(...) is called at 10 places in all the source and only ONE place to find a device. Sorry, I don't quite understand what you mean with that? > So let me augment my patch and insert in target_cmd_queue(...) a test for this. I believe this will cause requests to a server with a LUN-less target to simply fail until a LUN gets defined - just like an absent target. Here's a link to my patch submission 3 years ago: http://lists.wpkg.org/pipermail/stgt/2009-June/003003.html . It outlines a few more issues I had with the LUN 0. Here's a followup with slightly more information on why it was not merged: http://lists.wpkg.org/pipermail/stgt/2009-December/003427.html > BTW - this begs the question about when the sockets become available. I guess you mean the iSCSI socket? Shouldn't really matter, as you can block initiators from connecting as long as you're configuring your target - which you'll have to do if you want to replace the dummy device behind LUN 0 with a useful device. HTH, Arne -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
