From: Christoph Hellwig <hch@infradead.org>
To: Greg Banks <gnb@melbourne.sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>, Neil Brown <neilb@suse.de>,
Linux NFS Mailing List <nfs@lists.sourceforge.net>,
Linux Filesystem Mailing List <linux-fsdevel@vger.kernel.org>
Subject: Re: [NFS] [PATCH,RESEND] make knfsd interact cleanly with HSMs
Date: Tue, 9 May 2006 10:19:29 +0100 [thread overview]
Message-ID: <20060509091929.GA26236@infradead.org> (raw)
In-Reply-To: <1147142114.12319.94.camel@hole.melbourne.sgi.com>
On Tue, May 09, 2006 at 12:35:15PM +1000, Greg Banks wrote:
> So your only objection is the absence of DMAPI or some equivalent?
> If so, perhaps the best way forward in the short term is for SUSE
> to add it as an out-of-tree patch.
The objection doesn't have anything to do with DMAPI per see. It has to
do with adding kernel code that's never used in tree and thus bloats the
kernel. Also it has a fair chance to bitrot as there's no way it can be
tested.
p.s. -fsdevel couldn't care less about what patches you send to SuSE,
please stop posting such things here and talk to your SuSE technical contacts.
> Sure it's ugly, but to be fair it's no worse than SysV semaphores
> and shmem, and it does fill a real (albeit niche) need which nothing
> else does AFAIK. Compare to TLI, which is pretty much entirely useless.
It's fat worse because it makes assumptions that simply aren't true in
a unix or linux enviroment. SysV IPC is ugly but doesn't do this.
> > I don't expect anyone to submit a kernel-based
> > implementation for inclusion, although support for a big enough subset of
> > that standard could be archived by proper kernel <-> userspace cooperation.
>
> I don't understand what you mean here: surely almost all of what
> DMAPI specifies is for achieving proper kernel/userspace co-operation?
no. the DMAPI spec doesn't even know about the user <-> kernel boundary
nor should it.
> Do you have some ideas for a better way of doing that?
Yes, and I've written them up quite a few times, please look at the fsdevel
linux-kernel archives and possible some SGI-internal lists from years ago.
prev parent reply other threads:[~2006-05-09 9:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-05 11:52 [PATCH,RESEND] make knfsd interact cleanly with HSMs Greg Banks
2006-05-08 1:13 ` Neil Brown
2006-05-08 6:42 ` [NFS] " Christoph Hellwig
2006-05-08 11:16 ` Neil Brown
2006-05-08 11:37 ` Nathan Scott
2006-05-08 17:55 ` Christoph Hellwig
2006-05-09 2:35 ` Greg Banks
2006-05-09 9:19 ` Christoph Hellwig [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=20060509091929.GA26236@infradead.org \
--to=hch@infradead.org \
--cc=gnb@melbourne.sgi.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
/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).