From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: kristen.c.accardi@intel.com
Cc: ltuikov@yahoo.com, linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-ide <linux-ide@vger.kernel.org>,
jeff@garzik.org
Subject: Re: [PATCH] enclosure: add support for enclosure services
Date: Wed, 13 Feb 2008 12:17:09 -0600 [thread overview]
Message-ID: <1202926629.3109.63.camel@localhost.localdomain> (raw)
In-Reply-To: <20080213094502.4112d5e5@appleyard>
On Wed, 2008-02-13 at 09:45 -0800, Kristen Carlson Accardi wrote:
> 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.
I'm not necessarily arguing against that. However, what you're
providing is slightly more than just a userspace tap into the enclosure.
You're adding a file to display and control the enclosure state
(sw_activity). This constitutes an ad-hoc sysfs interface. I'm not
telling you not to do it, but I am pleading that if we have to have all
these sysfs interfaces, lets at least do it in a uniform way.
Enclosures are such nasty beasts, that even the job of getting a tap
into them is problematic, so if we have a different tap infrastructure
for every different enclosure type and connection it's still going to be
pretty unmanageable to a userspace 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.
James
next prev parent reply other threads:[~2008-02-13 18:17 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 21:40 [PATCH] enclosure: add support for enclosure services James Bottomley
2008-02-03 22:03 ` Sam Ravnborg
2008-02-04 0:16 ` James Bottomley
2008-02-06 0:12 ` Andrew Morton
2008-02-06 2:57 ` James Bottomley
2008-02-05 0:32 ` Luben Tuikov
2008-02-05 0:41 ` James Bottomley
2008-02-05 2:01 ` Luben Tuikov
2008-02-05 2:14 ` James Bottomley
2008-02-05 3:28 ` Luben Tuikov
2008-02-05 4:37 ` James Bottomley
2008-02-05 5:35 ` Luben Tuikov
2008-02-05 15:01 ` James Bottomley
2008-02-05 19:33 ` Luben Tuikov
2008-02-05 20:29 ` James Bottomley
2008-02-05 20:39 ` Luben Tuikov
2008-02-12 18:22 ` Kristen Carlson Accardi
2008-02-12 18:45 ` James Bottomley
2008-02-12 19:07 ` Kristen Carlson Accardi
2008-02-12 19:28 ` James Bottomley
2008-02-13 17:45 ` Kristen Carlson Accardi
2008-02-13 18:17 ` James Bottomley [this message]
2008-02-16 12:44 ` Pavel Machek
2008-02-13 9:48 ` Luben Tuikov
2008-02-13 14:08 ` James Smart
2008-02-13 16:04 ` James Bottomley
2008-02-13 16:22 ` James Smart
2008-02-13 16:43 ` James Bottomley
2008-02-13 16:49 ` James Smart
2008-02-12 19:45 ` Luben Tuikov
-- strict thread matches above, loose matches on Subject: below --
2008-02-13 11:15 Luben Tuikov
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=1202926629.3109.63.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=jeff@garzik.org \
--cc=kristen.c.accardi@intel.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ltuikov@yahoo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.