Re: software architecture/design question


Is A pretty much the same sort of hardware as B...G?
That's correct.

If so, then I don't think it should be up to A to understand the
configuration sequencing. IOW, A is just another device driver to be
configured by some unmentioned entity. One should separate the concerns
of configuration _within a system_ from the concerns of configuring
individual device drivers.
I suspect I could look at it that way. i.e device drivers.


OTOH, if A is explicitly responsible for managing the other cards in its
hardware specification (e.g., a VXI Slot 0 controller card), then A is
/supposed/ to understand the sequence. In that situation "hard-wiring"
the sequence in the A driver as you indicate below is quite reasonable...
No, A is not responsible for managing them. In fact I may end up usign
a GUI to drive configuration.


Whether this is ugly depends on how it is used. I assume there is a
generic card driver API that is invoked with the appropriate struct
information.
There's a generic driver API but this API has nothing to do with the
the struct thats passed to each processor indicating 'configure'. Put
it this way: Lets suppose you and I need to communicate with each
other. By communicate I mean we'll transmit say 4 MiB of data between
each other. You are desginated as - what's called a pseudo root.
Meaning if you're not up and running and I attempt to establish a
connection with you/I'll time out or I could wait _literally_ forever.
In an attempt to automate this. You'll receive a struct ( asssume now
that we're using a GUI ) that will tell you to configure. Upon receipt
of this struct. You'll create a 4 MiB buffer - a so called destination
channel. If you're successful at configuring this destination
channel, you'll report back your 'status'. Say you reported 'success'
to the GUI. The GUI will then ask me to configure. If successful,
I'll then report my status to the GUI and at this point you and I can
talk. i.e you can transfer 4MiB of data directly to my memory and vice
versa. It's a PCI translation that allows you to see my memory and
vice versa. All that's at the API driver level but has nothing to do
with the configure 'command' we'll receive from the outside world.


[Slot0Controller]
| 1
|
| R1 <<ordered>>
|
| configures
| * R2
[SlotCard] --------------- [SlotSpec]
* specifies 1

Now [SlotSpec] is a dumb data holder for the external configuration data
in your structs whose instances are initialized from the external data
at startup. Similarly, the external data identifies the slots (B, ...G)
so that the R2 relationship can be instantiated.

The sequence of initialization is defined in the order of the R1
relationship as the Slot0Controller "walks" the collection. That can
also be defined at startup fairly simply through the external
configuration data when SlotCards are added to the collection.

The advantage of this approach is that one can change the sequence and
the configuration details without touching the code in
[Slot0Controller]. One just needs to modify the external configuration
data in an appropriate manner. [If you are interested, the Invariants
and Parametric Polymorphism category of my blog has more detailed
examples of this sort of parametric polymorphism.]
I need to think more about this one.

.

Relevant Pages