Re: [PATCH] minimal SAS transport class

[Luben Tuikov <luben_tuikov@adaptec.com>]

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