Skip site navigation (1)Skip section navigation (2)
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>