From: Jeff Garzik <jeff@garzik.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Benny Halevy <bhalevy@panasas.com>,
Fred Isaman <iisaman@citi.umich.edu>,
Andy Adamson <andros@umich.edu>,
pnfs@linux-nfs.org, linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [pnfs] [PATCH 05/28] pnfsblock: expose scsi interface
Date: Wed, 12 Mar 2008 18:42:29 -0400 [thread overview]
Message-ID: <47D85C55.5060101@garzik.org> (raw)
In-Reply-To: <20080312164306.GA3519@infradead.org>
Christoph Hellwig wrote:
> On Wed, Mar 12, 2008 at 06:33:34PM +0200, Benny Halevy wrote:
>> This calls for a layering violation.
>>
>> To fill-in more context, here's an excerpt from the next patch,
>> showing how you use shost_class to scan all scsi disks:
>
> Yes, absolutely. No one outside of few places in the core scsi code
> should ever iterate over the scsi disks.
>
>> My question is how should a proper API between the scsi layer and
>> the block layout driver look like?
>>
>> Can you list your requirements, e.g.:
>> - scanning all available devices,
>>
>> - discovering new devices on the fly
>>
>> - getting notified for new devices?
>
> Neither. pnfs shouldn't open block devices from kernelspace at all,
> but do it's disovery in userspace.
>
> Or even better this whole block layout driver crap should go away
> completely and the people who have designed it beaten up until they
> aren't recognizable anymore.
The fact that NFSv4.1 requires SCSI is stupid crap, too.
The _design_ is a layering violation. I say we just say "no".
NFS _clients_ should not need to know deep device-level details about
how to store their data, and should not require SCSI in order to store data.
Jeff
prev parent reply other threads:[~2008-03-12 22:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1205263929-8346-1-git-send-email-iisaman@citi.umich.edu>
[not found] ` <1205263929-8346-2-git-send-email-iisaman@citi.umich.edu>
[not found] ` <1205263929-8346-3-git-send-email-iisaman@citi.umich.edu>
[not found] ` <1205263929-8346-4-git-send-email-iisaman@citi.umich.edu>
[not found] ` <1205263929-8346-5-git-send-email-iisaman@citi.umich.edu>
[not found] ` <1205263929-8346-6-git-send-email-iisaman@citi.umich.edu>
2008-03-12 16:33 ` [pnfs] [PATCH 05/28] pnfsblock: expose scsi interface Benny Halevy
2008-03-12 16:43 ` Christoph Hellwig
[not found] ` <2ea9cd5a0803121052p6569ff37l26a5448e588407ad@mail.gmail.com>
2008-03-12 18:10 ` Fredric Isaman
2008-03-12 18:36 ` Boaz Harrosh
2008-03-12 20:03 ` Christoph Hellwig
2008-03-12 20:30 ` Fredric Isaman
2008-03-12 22:42 ` Jeff Garzik [this message]
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=47D85C55.5060101@garzik.org \
--to=jeff@garzik.org \
--cc=andros@umich.edu \
--cc=bhalevy@panasas.com \
--cc=hch@infradead.org \
--cc=iisaman@citi.umich.edu \
--cc=linux-scsi@vger.kernel.org \
--cc=pnfs@linux-nfs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).