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

[Luben Tuikov]

--- On Tue, 2/12/08, James Bottomley James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > I understand what you are trying to do - I guess I
> just doubt the value
> > you've added by doing this.  I think that
> there's going to be so much
> > customization that system vendors will want to add,
> that they are going
> > to wind up adding a custom library regardless, so
> standardising those
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/