Re: software architecture/design question

Responding to Ma740988...

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.

OK, then A should not "own" the rules for the order of configuring the other cards.

The GUI and the A...G hardware are two entirely different subject matters with quite different paradigms. Each subject matter needs to be encapsulated in its own subsystems or layer. Ideally those subsystems would communicate through pure message (i.e., {message ID, <data packet>}) interfaces to decouple their implementations.

However, in this situation the software also needs to provide some domain rules at the system level that are related to things like sequencing the configurations properly. Those kinds of rules aren't relevant to the GUI paradigm (Window/Control) and they are probably not relevant to the particular hardware cards, which are individually "plug & play".

So I am suggesting that if A is pretty much the same as B...G, then those domain rules are at a higher level of abstraction (the aggregate of cards as a system) than the cards. Nor are they relevant to display paradigms like pixels and fonts. So they go somewhere else -- a subsystem or layer that understands the nature of the system itself. That subsystem or layer would act as a middleman between the user (GUI) and hardware (A...G drivers). It would "own" the sequencing rules.

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.

That's pretty much what I understood. If I am one of the A...G cards (or network ports or whatever) and you need to open a channel you are going to invoke my interface for openChannel(<struct>) where you pass me the relevant struct. I return a status data packet that you interpret to determine what to do subsequently (e.g., whether you can send me 4 MiB of data).

The API I am referring to is the openChannel call. I assume that will be the same regardless of which member the the A...G set you are actually talking to.

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

Since A...G are all pretty much the same, [Slot0Controller] would be the other software that understands the systems as a whole. I would expect all three of these objects to live in that other software. However, [SlotCard] is really just a place holder for the real card A...G that lives in the hardware access subsystem. The version in the hardware access subsystem would understand the mechanics of its own channel initialization and it would do the grunt work for PCI translation, etc.

The version here, though, only has enough information to form the openChannel message. That is, [SlotCard] has an ID for addressing the message to a particular A...G card instance in the hardware access subsystem and it acts as a place holder for ordering the R1 collection and mapping to the right configuration struct data in [SlotSpec]. IOW, it is a pretty dumb abstraction. But dumb abstractions are Good Things because they make the code simpler. B-)

[Note that [SlotCard] could be a Facade in case each A...G has its own namespace for openChannel. That is, [SlotCard] actually acts as the hardware access subsystem interface and invokes the API method on the corresponding card. So [Slot0Controller] always invokes SlotCard.openChannel here but the implementation of SlotCard.openChannel invokes B.createChannel or D.setup because it knows which type it really is.

But a better way is the the hardware access subsystem interface to provide a common openChannel(cardID, struct) API and let that Facade implementation dispatch to the right A...G card interface. The reason that is better is because it provides better decoupling of the "system" view from the "card" view. IOW, SlotCard.openChannel does not need to know anything at all about how the hardware access subsystem is organized.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • [git patches] net driver updates
    ... struct adapter { ... /* Translate scan data returned from the card to a card independant ... +static int __init nortel_pci_init ... * The driver implements Symbol firmware download. ...
    (Linux-Kernel)
  • [PATCH 4/4] netwave: move driver to staging
    ... Move the netwave driver to drivers/staging. ... tristate "Aviator/Raytheon 2.4GHz wireless support" ... Netwave AirSurfer Wireless LAN PC Card driver ... A struct pcmcia_device structure has fields for most things that are needed ...
    (Linux-Kernel)
  • [PATCH 01/13] Char: cyclades, add tty refcounting
    ... While this is not problem for Y card handlers (they are protected ... struct cyclades_port *info; ... unsigned int char_count; ...
    (Linux-Kernel)
  • [PATCH 08/79] cyclades: add tty refcounting
    ... While this is not problem for Y card handlers (they are protected ... struct cyclades_port *info; ... unsigned int char_count; ...
    (Linux-Kernel)
  • [PATCH 24/36] Driver core: convert sound core to use struct device
    ... everything show up properly in /sys/devices/ with symlinks from the ... It also makes the struct sound_card to show up as a "real" device ... and different card attribute files can hang off of. ... extern int snd_ecards_limit; ...
    (Linux-Kernel)