Date: Mon, 19 Jun 2000 18:35:01 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, Mike Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619183501.M37084@prism.flugsvamp.com> In-Reply-To: <20000619160518.F17420@fw.wintelcom.net> 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> <20000619160518.F17420@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 19, 2000 at 04:05:19PM -0700, Alfred Perlstein wrote: > * 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. Okay. > > > 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. I didn't know that you had to write the code in advance in order to have an architectural discussion. But as a matter of fact, I *DO* have working code, but I don't feel that it's in any form to be released at the moment, as its still evolving a bit. Put another way, I'm not waving my hands here and talking theory, I'm speaking from my own experience. > > > > 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. True. But if the syscalls change, the app needs to be recompiled. > > > 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. Fair enough. -- 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?20000619183501.M37084>