From: Pat LaVarre <p.lavarre@ieee.org>
To: dougg@torque.net
Cc: patmans@us.ibm.com, linux-scsi@vger.kernel.org
Subject: Re: sg utils sg_io -i 0x24 -y "12 00:00:00 24 00"
Date: 07 Nov 2003 10:09:29 -0700 [thread overview]
Message-ID: <1068224969.2286.142.camel@patrh9> (raw)
In-Reply-To: <1068224213.2286.115.camel@patrh9>
> > Perhaps we should be looking at
> > implementing camcontrol in Linux.
>
> Implementing, yes. Copying, no.
> I have a series of arguments, ...
>
> > Unix Man Page For 8 camcontrol
> > http://www.svbug.com/cgi-bin/man.cgi?comd=8+camcontrol
I think arg parsing is an issue.
I see the camcontrol man page includes such off-putting apologetic
fragments as:
"The sense information from the test unit ready command would not get
printed out, since the first getopt(3) call in camcontrol bails out when
it sees the second argument to -c (0x00), above.
"If the CDB specified causes data to be transfered to or from the SCSI
device in question, you MUST specify either
... -i len fmt ... -o len fmt [args] ..."
I particular want the common things to remain concise.
I choke over the idea of having to specify fmt in addition to len of -i
or -o.
Part of why I find plscsi/ unreadable, even though I wrote plscsi/
myself, is that in plscsi/ I resorted to rewriting getopts to fix this
kind of thing.
Since then I think I have by now found my way to a (more?) fully
getopt-compatible parsing of args. That gccscsi.h I posted #define's A
thru Z macros that correspond to proposed sg_io args -a thru -z.
1) That -d is unused appears as, e.g.:
#undef D
2) That some options exist only for the command line appears as, e.g.:
#undef P /* gcs --please */
The -p or --please option is an interlock. You have to add it to pass
thru such things as non-standard CDB lengths, the op x04 Format that
smashes disks, and the -y "12 00:00:00 00" Inquiry for Zero that crashes
many version of Linux 2.4.
3) Seeing that the args are single can be difficult, e.g.:
#define L(S, NS) gcs_late(gcs(), (S), (NS))
I figure at the command line we parse $s.fraction and convert to the
standard posix int pair (seconds, nanoseconds).
4) Seeing that the args are omitted or single can be easy, e.g.:
#define Q() gcs_quiet(gcs())
#define S(S) gcs_sense_in(gcs(), (S), 4, 0)
Pat LaVarre
next prev parent reply other threads:[~2003-11-07 17:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-07 0:38 sg utils sg_io -i 0x24 -y "12 00:00:00 24 00" Pat LaVarre
2003-11-07 16:24 ` Pat LaVarre
2003-11-07 16:56 ` Pat LaVarre
2003-11-07 17:09 ` Pat LaVarre [this message]
2003-11-07 17:17 ` Pat LaVarre
2003-11-07 17:51 ` Patrick Mansfield
2003-11-07 18:11 ` Pat LaVarre
2003-11-07 18:27 ` Pat LaVarre
2003-11-07 18:31 ` Pat LaVarre
2003-11-11 23:52 ` Pat LaVarre
2003-11-14 3:09 ` Douglas Gilbert
2003-11-26 16:15 ` Pat LaVarre
-- strict thread matches above, loose matches on Subject: below --
2003-11-27 17:15 Pat LaVarre
2003-12-03 0:17 Pat LaVarre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1068224969.2286.142.camel@patrh9 \
--to=p.lavarre@ieee.org \
--cc=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
--cc=patmans@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox