[Stgt-devel] vtl patch.

FUJITA Tomonori fujita.tomonori
Thu Apr 12 07:37:00 CEST 2007

From: "Mark Harvey" <markh794 at gmail.com>
Subject: Re: [Stgt-devel] vtl patch.
Date: Thu, 12 Apr 2007 15:07:31 +1000

> > I can't find "ElementType" in ssc3_config or smc_config. Will you
> > implement it later?
> Yes. I am in the process of implementing the this now. Nothing that
> actually compiles, let alone run.
> I am working on implementing the MODE SENSE/MODE LOG command, with
> initial config of page 0x1d (Element Address Assignment).
> I hope to post something new tomorrow so what was previously
> 'theoretical' will have some code example with what I'm trying to
> achieve.

I see. Thanks.

> > Do you need a configuration like 'only when X is true, Y is
> > necessary'?  I think that you can still do that with the current
> > semantics, 'one field at a time'. You just need to check whether the
> > configuration is valid when a user tries to start a target. Though
> > with a 'multiple fields at a time' scheme, the checking would be
> > a bit easier.
> >
> > I don't like '--name a --value b --name b --value c ...' because it
> > doesn't look like the standard (GNU) option way.
> I can't say I like it either, however it does seem to be the cleanest
> way.. I'm open to suggestions.
> Only other idea I had was to group up all non-processed arguments from
> the getopt_long(), re-format into a argc/argv[] type and pass this
> thru to the SMC/SSC module for additional processing. This would allow
> the SMC/SSC module to perform their own getopt_long()

How about somthing like this?

tgtadm --lld iscsi --mode logicalunit --op update --tid=1 --lun=0 \
        --params VendorIdent=QUANTUM,ProductIdent=SDLT600,ProductRev=0001

We can steal a parser for this from Linux kernel.

More information about the stgt mailing list