linux-kernel - Re: [PATCH] enclosure: add support for enclosure services

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080213094502.4112d5e5@appleyard>
Date:	Wed, 13 Feb 2008 09:45:02 -0800
From:	Kristen Carlson Accardi <kristen.c.accardi@...el.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	ltuikov@...oo.com, linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ide <linux-ide@...r.kernel.org>, jeff@...zik.org
Subject: Re: [PATCH] enclosure: add support for enclosure services

On Tue, 12 Feb 2008 13:28:15 -0600
James Bottomley <James.Bottomley@...senPartnership.com> wrote:

> On Tue, 2008-02-12 at 11:07 -0800, Kristen Carlson Accardi 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.
> 
> So, entirely as a straw horse, tell me what else your enclosures
> provide that I haven't listed in the four points.  The SES standards
> too provide a huge range of things that no-one ever seems to
> implement (temperature, power, fan speeds etc).
> 
> I think the users of enclosures fall int these categories
> 
> 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.  Could
> there be more ... sure; should there be more ... I don't think so ...
> that's what value add the user libraries can provide.
> 
> James
> 
> 

I don't think I'm arguing whether or not your solution may work, what I
am arguing is really a more philosophical point.  Not "can we do it
this way", but "should we do it way".  I am of the opinion that
management belongs in userspace.  I also am of the opinion that if you
can successfully accomplish something in user space, you should.  I
also believe that even if you provide this basic interface, all system
vendors are going to provide libraries on top of that to customize it,
so you've not added much value to just a simple message passing
interface.

So, I'm happy to defer to Jeff's judgement call here - I just want to
do what's right for our customers and get an enclosure management
interface for SATA exposed, preferrably in time for the 2.6.26 merge
window.  If he prefers your design, I'll disagree, but commit to his
decision and try to get this to work for SATA. If he'd rather see
something along the lines of what I proposed, then since it is 100% self
contained in the SATA subsystem, it shouldn't impact whatever you
want to do in the SCSI subsystem.

Jeff?

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