AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080618155149.57a86e10@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<chris.vandever@onstor.com>,<jonathan.goldick@onstor.com>,<maxim.kozlovsky@onstor.com>,<rendell.fong@onstor.com>,<james.kahn@onstor.com>,<jobi.ariyamannil@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 18 Jun 2008 15:57:35 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: Chris Vandever <chris.vandever@onstor.com>, Jonathan Goldick
 <jonathan.goldick@onstor.com>, Maxim Kozlovsky
 <maxim.kozlovsky@onstor.com>, Rendell Fong <rendell.fong@onstor.com>, James
 Kahn <james.kahn@onstor.com>, Jobi Ariyamannil
 <jobi.ariyamannil@onstor.com>
Subject: software architecture question
Message-ID: <20080618155735.635e160b@ripper.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Context:

I'm working some more changes to consolidate reboot functionality in
our userspace code, as first started by me, then progressed some more by
Chris, and now back to me for more.

The code paths involving _system upgrade -p_ (upgrade the primary
flash) and _system reboot_ try to offline all the volumes (which is
skipped in the _system reboot_ case if you supply the -f option).
Possibly several other code paths should try to offline the volumes as
well (???), so I'm considering how to move that functionality into a
common reboot routine.

Problem:

The vol_offline_all() function, and another function it calls, are
implemented currently in nfx-tree/ssc-nfxsh/cmd_vol.c.  I could just
move that code into the sm-utils/sys-utils.c code I'm hacking on now,
but I'm thinking shouldn't this sort of thing be some kind of vol API
type routine?   Currently vol_offline_all() appears to be callable with
a VSID and presumably offlines just that vsvr's volumes, or with -1 to
offline all volumes on this filer.

Max mentioned that most likely the code that implements this should go
in the vsd daemon, and perhaps that's true, but then we still would need
an API type function that does the work of sending the message to vsd.
Where would be the right place for such code to reside?

Cheers,

a
