Date: Mon, 19 Jun 2000 16:05:19 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619160518.F17420@fw.wintelcom.net> In-Reply-To: <20000619175805.J37084@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Mon, Jun 19, 2000 at 05:58:05PM -0500 References: <20000619164329.F37084@prism.flugsvamp.com> <200006192156.OAA09767@mass.osd.bsdi.com> <20000619172041.G37084@prism.flugsvamp.com> <20000619153325.D17420@fw.wintelcom.net> <20000619175805.J37084@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jonathan Lemon <jlemon@flugsvamp.com> [000619 15:53] wrote: > On Mon, Jun 19, 2000 at 03:33:25PM -0700, Alfred Perlstein wrote: > > For which it is a very specific problem, and I'm trying to expand > it a little bit so it can be used for other things as well. Ok, here's what I'll do, I'll also provide for a way to create a kblob and tell the kernel to read the data from an already open file. > > So then use my soon to be committed accept filters to accomplish this. > > How is this applicable? The accept filters just delay telling the > user when data is available, not redirect the data. None of the patches you've present do either. > > > 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? > > > > I'm not opposed to it at all, feel free to work on the code as much > > as you want as long as you don't kill the fastpath it offers. > > Sure, as long as you don't mind me ripping out your API later, and > replacing it with something which accomplishes the same thing but > is more flexible. If it's flexible enough then you won't need to rip out my API, you'll find it obnoxiously easy to create compatibility shims for it. > > > > If you have a Grand Plan for something else, that's great - I'd recommend > > > > you keep working on it. In the meantime, there are a lot of people that > > > > can do a lot of useful things with kblob as-is, and knocking it down just > > > > because it's not _your_ idea of the Perfect In-Kernel Network Container > > > > Object is kinda silly. > > > > > > Well, with a little more work, we can get something that is more > > > applicable to a wider audience, rather than focusing on your single > > > specific performance problem. Putting on blinders to the wider > > > problem simply because your current code doesn't address it strikes > > > me as kind of foolish. > > > > The only problem I see is that there's just no pleasing some people. > > :) > > > > I'm not writing this code for your application Johnathan, I'm > > writing it for myself and for the other people that need this > > functionality. > > Fine. I'm not complaining about your functionality, I'm complaining > about your API. In one of my last messages, I presented a list of > things I wanted to accomplish with in-kernel buffers. Now, I don't > explect you to implement the code for it, but I also don't expect > you to stick with such a narrow API that makes those aims impossible to > accomplish in the future. I never said that the code will be set in stone. I won't stand in the way of your enhancements. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20000619160518.F17420>