On Wed 2008-02-13 09:45:02, Kristen Carlson Accardi wrote:
> On Tue, 12 Feb 2008 13:28:15 -0600
> James Bottomley <[EMAIL PROTECTED]> 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 y
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
On Tue, 12 Feb 2008 13:28:15 -0600
James Bottomley <[EMAIL PROTECTED]> 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 muc
James Bottomley wrote:
... I wouldn't have bothered except that I could see ad-hoc
in-kernel sysfs solutions beginning to appear.
If this is true, and if no one quickly volunteers to do the utility, then
I agree with what you are doing.
-- james s
-
To unsubscribe from this list: send the li
On Wed, 2008-02-13 at 11:22 -0500, James Smart wrote:
> James Bottomley wrote:
> > I don't disagree with that, but the fact is that there isn't such a
> > tool. It's also a fact that the enterprise is reasonably unhappy with
> > the lack of an enclosure management infrastructure, since it's somet
James Bottomley wrote:
I don't disagree with that, but the fact is that there isn't such a
tool. It's also a fact that the enterprise is reasonably unhappy with
the lack of an enclosure management infrastructure, since it's something
they got on all the other unix systems.
I don't disagree.
On Wed, 2008-02-13 at 09:08 -0500, James Smart wrote:
> The keep-it-in-user-space arguments seem fairly compelling to me.
> Especially as we've pushed whole i/o subsystems out to user space
> (iscsi, stgt, talked about fcoe, a lot of dm control, etc).
And to me too.
> The functionality seems to a
The keep-it-in-user-space arguments seem fairly compelling to me.
Especially as we've pushed whole i/o subsystems out to user space
(iscsi, stgt, talked about fcoe, a lot of dm control, etc).
The functionality seems to align with Doug's sg/lsscsi utility chain
as well. Granted, the new utility w
--- On Tue, 2/12/08, James Bottomley [EMAIL PROTECTED]> 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
> >
--- On Tue, 2/12/08, James Bottomley [EMAIL PROTECTED]> wrote:
> > I apologize for taking so long to review this patch.
> I obviously agree
> > wholeheartedly with Luben. The problem I ran into
> while trying to
> > design an enclosure management interface for the SATA
> devices is that
> > there
--- On Tue, 2/12/08, Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote:
> Hi,
> I apologize for taking so long to review this patch. I
> obviously agree
> wholeheartedly with Luben. The problem I ran into while
> trying to
> design an enclosure management interface for the SATA
> devices is that
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
On Tue, 12 Feb 2008 12:45:35 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-02-12 at 10:22 -0800, Kristen Carlson Accardi wrote:
> > I apologize for taking so long to review this patch. I obviously
> > agree wholeheartedly with Luben. The problem I ran into while
> > trying to d
On Tue, 2008-02-12 at 10:22 -0800, Kristen Carlson Accardi wrote:
> I apologize for taking so long to review this patch. I obviously agree
> wholeheartedly with Luben. The problem I ran into while trying to
> design an enclosure management interface for the SATA devices is that
> there is all thi
On Mon, 4 Feb 2008 18:01:36 -0800 (PST)
Luben Tuikov <[EMAIL PROTECTED]> wrote:
> --- On Mon, 2/4/08, James Bottomley
> <[EMAIL PROTECTED]> wrote:
> > > > The enclosure misc device is really just a
> > library providing
> > > > sysfs
> > > > support for physical enclosure devices and their
> > > >
On Tue, 2008-02-05 at 16:12 -0800, Andrew Morton wrote:
> On Sun, 03 Feb 2008 18:16:51 -0600
> James Bottomley <[EMAIL PROTECTED]> wrote:
>
> >
> > From: James Bottomley <[EMAIL PROTECTED]>
> > Date: Sun, 3 Feb 2008 15:40:56 -0600
> > Subject: [SCSI] enclosure: add support for enclosure services
On Sun, 03 Feb 2008 18:16:51 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
>
> From: James Bottomley <[EMAIL PROTECTED]>
> Date: Sun, 3 Feb 2008 15:40:56 -0600
> Subject: [SCSI] enclosure: add support for enclosure services
>
> The enclosure misc device is really just a library providing sysf
--- On Tue, 2/5/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > Wrong ... we don't export non-SCSI devices as
> SCSI
> > > (with the single and
> > > rather annoying exception of ATA via SAT).
> >
> > I didn't say you should do that. I had already
> > mentioned that vendors export such contr
On Tue, 2008-02-05 at 11:33 -0800, Luben Tuikov wrote:
> > Wrong ... we don't export non-SCSI devices as SCSI
> > (with the single and
> > rather annoying exception of ATA via SAT).
>
> I didn't say you should do that. I had already
> mentioned that vendors export such controls
> as either enclos
--- On Tue, 2/5/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > > I guess the same could be said for STGT and
> SCST,
> > > right?
> > >
> > > You mean both of their kernel pieces are modular?
>
> > > That's correct.
> >
> > No, you know very well what I mean.
> >
> > By the same logic you
On Mon, 2008-02-04 at 21:35 -0800, Luben Tuikov wrote:
> > > I guess the same could be said for STGT and SCST,
> > right?
> >
> > You mean both of their kernel pieces are modular?
> > That's correct.
>
> No, you know very well what I mean.
>
> By the same logic you're preaching to include your
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > --- On Mon, 2/4/08, James Bottomley
> <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2008-02-04 at 18:01 -0800, Luben Tuikov
> wrote:
> > > > --- On Mon, 2/4/08, James Bottomley
> > > <[EMAIL PROTECTED]>
> wrote:
> > > > > > > The enclosu
On Mon, 2008-02-04 at 19:28 -0800, Luben Tuikov wrote:
> --- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > On Mon, 2008-02-04 at 18:01 -0800, Luben Tuikov wrote:
> > > --- On Mon, 2/4/08, James Bottomley
> > <[EMAIL PROTECTED]> wrote:
> > > > > > The enclosure misc device is really
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-02-04 at 18:01 -0800, Luben Tuikov wrote:
> > --- On Mon, 2/4/08, James Bottomley
> <[EMAIL PROTECTED]> wrote:
> > > > > The enclosure misc device is really
> just a
> > > library providing
> > > > > sysfs
> > > > > suppo
On Mon, 2008-02-04 at 18:01 -0800, Luben Tuikov wrote:
> --- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > > The enclosure misc device is really just a
> > library providing
> > > > sysfs
> > > > support for physical enclosure devices and their
> > > > components.
> > >
> > > W
--- On Mon, 2/4/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> > > The enclosure misc device is really just a
> library providing
> > > sysfs
> > > support for physical enclosure devices and their
> > > components.
> >
> > Who is the target audience/user of those facilities?
> > a) The kernel it
On Mon, 2008-02-04 at 16:32 -0800, Luben Tuikov wrote:
> --- On Sun, 2/3/08, James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > The enclosure misc device is really just a library providing
> > sysfs
> > support for physical enclosure devices and their
> > components.
>
> Who is the target audience/
--- On Sun, 2/3/08, James Bottomley <[EMAIL PROTECTED]> wrote:
> The enclosure misc device is really just a library providing
> sysfs
> support for physical enclosure devices and their
> components.
Who is the target audience/user of those facilities?
a) The kernel itself needing to read/write SE
On Sun, 2008-02-03 at 23:03 +0100, Sam Ravnborg wrote:
> Hi James.
>
> Nitpicking only.
>
> Sam
Thanks for the review.
> > +
> > if MISC_DEVICES
>
> Unrelated change.
Yes, removed it.
> > +config ENCLOSURE_SERVICES
> > + tristate "Enclosure Services"
> > + default n
> Not needed.
Hi James.
Nitpicking only.
Sam
> The enclosure misc device is really just a library providing sysfs
> support for physical enclosure devices and their components.
>
> Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
> ---
>
> See the additional ses patch for SCSI enclosure services u
The enclosure misc device is really just a library providing sysfs
support for physical enclosure devices and their components.
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
See the additional ses patch for SCSI enclosure services users of this.
---
drivers/misc/Kconfig | 10 +
31 matches
Mail list logo
