From owner-freebsd-hackers Fri Oct 18 07:51:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA27819 for hackers-outgoing; Fri, 18 Oct 1996 07:51:09 -0700 (PDT) Received: from plains.nodak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA27811; Fri, 18 Oct 1996 07:51:06 -0700 (PDT) Received: (from tinguely@localhost) by plains.nodak.edu (8.7.6/8.7.3) id JAA29942; Fri, 18 Oct 1996 09:51:00 -0500 (CDT) Date: Fri, 18 Oct 1996 09:51:00 -0500 (CDT) From: Mark Tinguely Message-Id: <199610181451.JAA29942@plains.nodak.edu> To: julian@whistle.com Subject: Re: custom free for external mbuf Cc: freebsd-atm@freebsd.org, freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk a little more background: traditionally, devices tell us how much space it needs just before we do the DMA, this card needs (up to 1024) buffers programmed into a queue before data arrives. We get these buffers back when they are full, or at the end of the packet. We have to feed new buffers into the card and consume data. we need buffers in the card for new input, some buffers will be running through the stacks, some beffers will be waiting to be put into the card. The data buffer has to be around forever, and to have the packet consuption routines deallocating the mbuf structure, only to turn around and reallocate either at packet recieve interrupt time or right away when I put it back on the card's queue seems wasteful. julian@whistle.com says: > you are looking at a very old version..... > look at 2.2 let us not say 2.1.5-RELEASE is old. :) > sure why not, but don't break what's already there.. > please go look at 2.2 before changing things > the routine is only ever called from there, > but the function pointers might be set up in many palces.. > especially in 3rd party software.. > so don't break it...please (I agree, ** WARNING: I am a little preachy below **. for the hysterical-intolarent, below rants about people that can but shouldn't change an existing external free routine). SOMEONE BETTER NOT BE CHANGING AN EXISTING FREE FUNCTION, THEY HAVE NO RIGHT TO DO THAT unless they retain the ORIGINAL free operation AFTER they handled their case. Reading between your lines, it appears we agree that if someone says they have and external free routine, they want it honored. I own these buffers, and I do not want anyone higher on the stack to mess with my free routine. It should matter if I am requesting the freeing of the external data or freeing of the mbuf structure itself, no one should mess with my function request. The problem very few people use these specified external free function, so the odds are it is not set before you put in a function (I bet you don't even check). Let us say more drivers use them (and once one does then you have to assume that anyone below you could). Now what are you going to do to specify your external free? from your prosective, that other driver broke your code. If you change my external free function you broke my code. come on, this external free function idea has been around for several years, people must have had this problem before. Do we need a FIFO of functions (and flags if I add a flag that changes the parameter) or do we tell all designers of external free functions they MUST save the pre-existing external free function (and flag for the same reason as above) and they MUST (restore the flag and) call the pre-existing external free AFTER executing their code. And would the same apply to the external reference now in the 2.2 code? we can delay this problem by saying that will have to change my design and I can't reserve these buffers and I will have to allocate every buffer on the fly, but this is not going to solve the problem of the future when two stacks using the same buffer want to use the external free function and would the same go for the external reference function. (now slipping into silly mode) tell me friends, do you want big government (mbuf structure changes to give us a FIFO of routines), or local solutions (make the driver writers to do the right thing). If elected, I promise ... #include --mark.