Date: Thu, 28 Jan 1999 17:04:06 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Emmanuel Duros <Emmanuel.Duros@sophia.inria.fr> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: rules to allocate buffers in device drivers Message-ID: <Pine.BSF.4.05.9901281613040.81323-100000@bright.fx.genx.net> In-Reply-To: <199901281349.OAA24119@chouette.inria.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Jan 1999, Emmanuel Duros wrote: > > Hi, > > I am currently writing a network device driver for FreeBSD and it is > still unclear to me how to allocate memory. > > It seems that a common way of doing it is something like: > > u_char *buffer; > buffer = malloc( SIZE, M_DEVBUF, M_NOWAIT); > > However I have not seen something like this in a device driver: > > u_char buffer[SIZE]; > > Is there a particular reason for not allocating buffers statically ? > Pointing out files and line numbers in the code helps a lot, however as i understand it, the reason buffers aren't like: u_char buffer[SIZE]; is because there is a very limited intrupt stack (MSmith told me 16k?) if you exhaust that, it's not a very good thing. using malloc with NOwait set allows you to hopefully retry a transfer at a different time. however sometimes you will see something like: u_char stkbuffer[20]; u_char *buf; buf = ( nbytes <= 20 ) ? &(stkbuffer[0]) : (u_char*) malloc(...); the reason the above is done is to avoid a call to malloc if the amount of buffer space is usually going to be small and could be fit on the stack. > I have not found anything related to how to allocate memory in kernel > code (definitions of malloc parameters, etc.). Do you have any pointer > on that ? man 9 malloc Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 4.0-current To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901281613040.81323-100000>