Date: Mon, 19 Jun 2000 19:46:09 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619194609.N37084@prism.flugsvamp.com> In-Reply-To: <200006192345.QAA10193@mass.osd.bsdi.com> References: <20000619182730.L37084@prism.flugsvamp.com> <200006192345.QAA10193@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 19, 2000 at 04:45:15PM -0700, Mike Smith wrote: > > 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. I must not be trying hard enough. What I have is a *superset* of kblob. It solves the *same* problem, but can also do additional things. It does roughly exactly what kblob does, in the same fashion. (no vm mapping games). > > > > > 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. I'm not claiming that about what I have. If I thought it was perfect, I would have submitted it for inclusion. All I'm trying to do is expand the API so it can handle other uses as well. > > 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, it just happens to be my *job* at the moment. > > > > > 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. I think we must be talking at cross purposes. My question wasn't rhetorical, and I must be missing your point. > > > 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. I'm not objecting to the code, nor the concept, I'm just trying to make the api flexible enough to handle things which I would like to add later. Yes, I have code that will do the above, but no, I don't feel that it is quite polished enough to put in the public release kernel. It is my understanding now that this will be done as a loadable syscall, so with that in mind, I guess getting the API correct is not paramount any more, so I'll shut up for a bit. -- Jonathan 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?20000619194609.N37084>