On 08/29/05 13:16, Christoph Hellwig wrote: > > No need to do silly renaming, but yes, moving creating of scsi_target I'd do the "silly renaming". I'd also create "struct scsi_domain_device", and do "scsi_register_domain_device()". You know, clean slate... > structures to the transport does make sense. It's kinda implicit There is *nothing* implicit in a Software Project Specification! Everything must be completely explicit. > in the todo list I posted. I also don't really see the point of > the embedded kobject. You will, once I post my code. Think, - Hotplugging. - More than one "owner" from above. That is, on a transport you can have a diverse set of devices. What if queuecommand() was *not* the only way to send a task to the device? ;-) > We actually already have a list in the scsi_target that chains of the > scsi_device, .devices in scsi_target and .same_target_siblings in scsi_device. > We just need to use it everywhere. Yes, I've seen all this. And I'm sorry to say, but it is *UGLY AS HELL!* As I said: before implementing an object by a structure in a software project one has to ask themselves what that object is? How will it play with the rest of the objects existsing or to be designed? What are the dependencies and what is the dependency graph? Etc. First it starts with a white sheet of paper, pencil on one side and a spec on the other. > Yes. that's what I ment with my item (3) (sorry, I hate all this > techno-babble, simple language is much easier to understand normally) Ok, sorry, it's that software specificaion "tehcno-babble" thing talking through me again. Luben - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
