[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-scsi
Subject:    Re: [PATCH] minimal SAS transport class
From:       Luben Tuikov <luben_tuikov () adaptec ! com>
Date:       2005-08-29 18:34:49
Message-ID: 43135549.9050703 () adaptec ! com
[Download RAW message or body]

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
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]