James C. McPherson wrote:
> On Thu, 13 Nov 2008 20:33:36 -0800
> Matthew Jacob <Matthew.Jacob at Sun.COM> wrote:
>
>
>> Garrett D'Amore wrote:
>>
> ...
>
>>> These days we have libscsi and friends. Application developers
>>> should be able to use those directly.
>>>
>> You're kidding, right?
>>
>> ultra20 > man libscsi
>> No manual entry for libscsi.
>>
>> Looking at the case materials for 2008/196 (which, btw, is a painful
>> process when going through opensolaris.org), libscsi, and libses, are
>> built on top of sgen(7d). Jesus wept, this misses the points I've
>> been trying to make.
>>
>
>
> No, he's not kidding. This is pretty much the same question
> I asked last week.
>
> Just because there's no manpage doesn't mean that it's impossible
> to use - or don't people read source code any more?
>
> libses makes use of sgen(7d), but libscsi doesn't mandate use
> of libses.
>
> Pluggable fwflash(1m) uses both libscsi and libses, and the code
> for almost of it is open.
>
> What's your underlying objection to using libscsi and/or libses?
>
Right. (Although are those APIs public commitment? Maybe a better case
would be to elevate their commitment level. I'm not sure.)
And I think Matthew missed one more point, when he claimed that
> Which end-users? If the end-user is a developer, the bits should live
> in something describe in PATH. If the end-user isn't a developer, the
> bits shouldn't matter where they live because the non-developer won't
> be using them (unless they act as a pseudo-developer installing a
> scanner to their system, fervently wishing that they'd installed
> Leopard instead...).
My point is that if the consumer here is layered software, rather than
someone typing these commands on a command line, then they don't belong
in the PATH.
I still haven't got an answer about that. What is the target audience
here? Do we expect ordinary folks to be typing these commands? (I'm
not talking about someone manually using it to debug their application.
We don't put /usr/lib/mixer_applet2 in /usr/sbin, although someone
debugging audio might have cause to run it manually (I have done so!)..
What I was talking about was whether folks would run this as a normal
course of action during their work. (Developer or otherwise.)
Example: snoop is useful for diagnostics, and while many people are
blissfully ignorant of it, it is typically run on the command line. tcp
wrappers, on the other hand, are normally not run by someone typing the
name of the command.)
The other question, which was ignored, is that if the intent here is
that this is for use primarily as a building block for layered software,
is there any layered software which exists that builds on it. I
understand adding building blocks that we need, and even adding
duplicates when there is demand for the specific duplicate. But if
there is no demand, then frankly unless there is some other
justification (like users want to type this at the command line), then I
don't see a reason for us to be muddying the architectural waters by
providing choices that aren't being asked for.
I know, I know... I'm a bit crotchety because I still haven't been
convinced that just because you *can* ship a piece of software it
doesn't mean you *should*, despite the current trend of "integrate
everything *and* the kitchen sink, useful or otherwise, into Solaris."
I'm on sabbatical, so I'll shut up now... Although I'd still like to see
answers to my fundamental questions, you're not obliged to answer them.
You can consider my concerns as heckling coming from the peanut gallery
if you prefer.
-- Garrett
