From owner-freebsd-net Tue Feb 6 19:42:48 2001 Delivered-To: freebsd-net@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 30A4E37B491; Tue, 6 Feb 2001 19:42:27 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G8DBJZ05.88O; Tue, 6 Feb 2001 22:40:47 -0500 Message-ID: <003001c090b8$0b067a50$1f90c918@jehovah> From: "Bosko Milekic" To: "Boris Popov" , Cc: References: Subject: Re: Sequential mbuf read/write extensions Date: Tue, 6 Feb 2001 22:42:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Boris Popov wrote: [...] > Since currently there isn't many consumers of this code I can > suggest to define an option LIBMBUF in the kernel configuration file and > add KLD libmbuf (with interface libmbuf), so kernel footprint will not be I am in favor of such an option on the condition that it is temporary. In other words, only until we decide "we have converted enough code to use this code so we should remove the option now." The reason is that otherwise, we will be faced with numerous "#ifdef LIBMBUF ... #else ... #endif" code. I assume this is what you meant, anyway, so I have no objections. :-) The API looks great by the way, and I will try to give a more detailed review in the next few days. :-) For now: #define M_TRYWAIT M_WAIT is not right. (M_WAIT is no longer to be used in the mbuf code.) The succesfull return values are 0, I don't have a problem with this, specifically, but I would assume that this: if (!mb_init(mbp)) ... would be more "logical" (I use the term loosely) if it meant: "if initialization fails" (now it means "if initialization is succesful"). > significantly affected. The names of source and header files are > questionable too and I would appreciate good suggestions (currently they > are subr_mbuf.c and subr_mbuf.h). Hmmm. Maybe subr_mblib.c and libmb.h ? I don't want to turn this into a bikeshed ( :-) ), so I suggest that you decide. Personally, I would prefer that it be something other than "subr_mbuf.c" simply because it may be a little misleading in some cases. > Well, and finally here you will find full source code of proposed > API: http://www.butya.kz/~bp/mbuf/ > > Any comments and suggestions are greatly appreciated. > > -- > Boris Popov > http://www.butya.kz/~bp/ Boris, this is really a great interface and nice looking, clean code. Thank you! Regards, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message