From: James Bottomley <James.Bottomley@SteelEye.com>
To: dougg@torque.net
Cc: Andrew Morton <akpm@osdl.org>,
linux-scsi@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] procfs support for sgiwd93
Date: Wed, 19 Oct 2005 17:40:33 -0400 [thread overview]
Message-ID: <1129758034.9618.14.camel@mulgrave> (raw)
In-Reply-To: <43538988.3000204@torque.net>
On Mon, 2005-10-17 at 21:22 +1000, Douglas Gilbert wrote:
> Is there any such policy?
Yes, there is. It's not actually mine, it's the direction coming out of
several kernel summits. /proc is to be moved back to handling process
information. /sys should be used for other ancillary information
exporting.
This policy can be interpreted with some elasticity depending on what an
author wants to do.
> Christoph Hellwig previously has used this purported policy
> to reject scsi procfs bug fixes:
> "[PATCH] scsi: /proc/scsi/scsi patch for large number of devices"
> As for alternate tools to 'cat /proc/scsi/scsi', I
> am not aware of many distributions using lsscsi (debian
> and gentoo do), perhaps there are other tools. I
> suspect a lot of folks are still using 'cat /proc/scsi/scsi'.
/proc/scsi/scsi has an awful lot of failure cases. The most annoying
one seems to be periodically losing hot added devices.
The reason for not fixing something if it's not a severe bug is simply
that if we keep /proc/scsi/scsi fully functional and up to date, then
the distributions will have no incentive to move away from it.
> Does Christoph Hellwig have the right to NACK/veto
> etc work that is not his when you are the SCSI maintainer?
Technically no-one truly gets a veto since there are many ways code can
end up in the vanilla kernel; however, everyone gets to express their
opinion ...
James
next prev parent reply other threads:[~2005-10-19 21:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-15 1:38 [PATCH] procfs support for sgiwd93 Ralf Baechle
2005-10-17 10:19 ` Arjan van de Ven
2005-10-17 10:55 ` Douglas Gilbert
2005-10-17 11:25 ` Arjan van de Ven
2005-10-17 10:43 ` Christoph Hellwig
2005-10-17 10:47 ` Ralf Baechle
2005-10-17 10:49 ` Christoph Hellwig
2005-10-17 11:22 ` Douglas Gilbert
2005-10-19 21:40 ` James Bottomley [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-10-20 18:04 Ralf Baechle
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=1129758034.9618.14.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=dougg@torque.net \
--cc=hch@infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ralf@linux-mips.org \
/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.