Date: Mon, 19 Jun 2000 16:45:15 -0700 From: Mike Smith <msmith@freebsd.org> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <200006192345.QAA10193@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 19 Jun 2000 18:27:30 CDT." <20000619182730.L37084@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Jun 19, 2000 at 04:11:59PM -0700, Mike Smith wrote: > > > And as far as "zero-copy" goes, I would consider that a fairly overloaded > > > term. Here, I'm applying it to anything that saves copies, not just > > > a magical method of getting data between user and kernel spaces. > > > > Correct. Note that kblob doesn't involve any more copies than absolutely > > necessary. > > Not quite true. You can't load your "static image" into the > kernel directly from disk. You have to go through userspace. > That counts as an extra copy in my book. Now it may be true > that you may not need to do this for _YOUR_ application, but > that may not be applicable for mine. I think I've tried hard enough to make it clear that your application requires your solution, but that kblob is a solution to a rather different problem. > > > > Irregardless, this is irrelevant in this context. > > > > > > Not irrelevant; you're not looking at the big picture here. > > > > Actually, I think I'm looking at a *bigger* picture - what can we do to > > make FreeBSD a better platform for real-world applications? > > > > The ability to send static content in the most efficient manner possible > > is a key "big picture" item. You're so tied up in what would be the most > > wonderful engineering solution that you're completely ignoring this. > > Gee, really? Please explain to me in small words how what I'm > trying to accomplish is contrary to what you're saying above. Please > explain how the rough API I posted is at all at odds to above. Please > explain to me how "static content" is the end-all and be-all "big picture". I've never claimed that it's the "be-all and end-all" big picture. That's your claim, about your proposal. As I've said time and time again, kblob is a specific solution to a specific problem. > Until you do so, I will keep going and solving some real-world > applications that are larger than just serving static content. That's sheer arrogance. 8( > > > > No. Since the data in a kblob came from userspace, and can't be modified > > > > in the kernel, this would be pointless. > > > > > > Exactly. You're looking at kblob as a "static send-only buffer which > > > comes from user space". I'm looking at kblob as an "in-kernel object > > > cache". The two views are _NOT_ that far apart, and with a little API > > > help, the current code can be made much more flexible. Why are you > > > opposed to that? > > > > Why would anyone be opposed to putting a Perl interpreter in the kernel? > > And I thought that -arch was supposed to be a technical list, not the > place for ad homenium attacks. That's pretty lame. Especially since the question was rhetorical and quite applicable to the point I was trying to make. > > You're welcome to your API, but you need to face the fact that it's just > > as irrelevant to kblob's target audience as kblob is to you. > > Methinks that you haven't actually read what I posted, otherwise > you wouldn't be saying that. One could draw the same conclusion in reflex. Why not simply accept the fact that right now you're competing against functional code, and come up with a competitive alternative? Right now, all we've got from your corner is vapourware - nobody is going to dispute that if you can make your code do what kblob does at a comparable cost, and it's more versatile, it'll be the winner. The issue right now is that all of the proposals so far have been too expensive, and entirely lacking in implementation. Under those circumstances you're better off coding than bitching while someone else deploys something that solves their problems. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006192345.QAA10193>