Re: [PATCH] enclosure: add support for enclosure services

--- On Tue, 2/12/08, James Bottomley James.Bottomley@HansenPartnership.com> wrote:

quoted

I understand what you are trying to do - I guess I

just doubt the value

quoted

you've added by doing this.  I think that

there's going to be so much

quoted

customization that system vendors will want to add,

that they are going

quoted

to wind up adding a custom library regardless, so

standardising those

quoted

few things won't buy us anything.

It depends ... if you actually have a use for the
customisations, yes.
If you just want the basics of who (what's in the
enclousure), what
(activity) and where (locate) then I think it solves your
problem almost
entirely.

If the kernel doesn't solve it "entirely", then it is better
off without the kernel bloat.  In fact vendors would distribute
their own user-space application(s) to provide a consistent and
complete solution(s) of their product(s) to their customer(s).

This could also be achieved via "sg_ses", which can also
control custom vendor pages if the encodings are known by the
customer (which they would be if they purchased the product).

So, entirely as a straw horse, tell me what else your
enclosures provide
that I haven't listed in the four points.

You shouldn't insist on this.  It should already be clear
to you this direction isn't the vendor's preference.

 The SES
standards too provide
a huge range of things that no-one ever seems to implement
(temperature,
power, fan speeds etc).

Vendors do use "temperature, power and fan speeds" and
in fact more features, some of them completely custom
for their product, since they end up writing the SES
device server of the enclosure themselves (for their product).
This kind of control and representation is better left to
user-space.  The kernel neither needs to represent it
nor know about it, since it is itself not using nor
controlling it.

I think the users of enclosures fall int these categories

This statement (above) really means that the numbers below
are but merely the speculation of one person.

85% just want to know where their device actually is (i.e.
that sdc is
in enclosure slot 5)
50% like watching the activity lights
30% want to be able to have a visual locate function
20% want a visual failure indication (the other 80% rely on
some OS
notification instead)

When you add up the overlapping needs, you get about 90% of
people happy
with the basics that the enclosure services provide.

90% doesn't make it a necessary requirement for the kernel
to have this, as well as the fact that the kernel is neither
needing this to function properly, nor using it.

Could there be more ... sure; should there be more ... I don't think
so ... that's what value add the user libraries can provide.

"should there be more ... I don't think so"

This decision isn't yours to make.  In fact such a decision is never
made by one person only.  This decision is made by 1) the industry,
2) the customers and 3) vendors by the pricing of their product(s).

   Luben