On 08/29/05 13:31, Luben Tuikov wrote: > 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? ;-) Forgot to mention one more thing, which I'm sure you're aware of: *If* the kobject hierarchy is set right, then kobject_get() "gets" this object and _all_ objects which are "parents" of this object. And kobject_put() "puts" all objects which are "parent" of this object, including calling the release method of each.(*) You'll need this to support hotplugging on the fly... Luben (*) Thus if your sysfs tree is built as the physical world looks(**), you lock the object(s) when you use them, so that if any "intervening" object is removed and you get an event notification for it, you know what to do... ;-) (**) Which the "transport class" doesn't give you, since it was never _designed_ for that purpose... unless of course you slice-it-and-dice-it pretty well. ;-) > > >>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 > - : 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
