Date: Thu, 4 Jul 2002 14:29:36 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Julian Elischer <julian@elischer.org> Cc: Neal Fachan <neal@isilon.com>, Terry Lambert <tlambert2@mindspring.com>, Garrett Wollman <wollman@lcs.mit.edu>, Jonathan Lemon <jlemon@flugsvamp.com>, current@FreeBSD.ORG Subject: Re: additional queue macro Message-ID: <Pine.GSO.4.10.10207041414510.17696-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0207041030070.6975-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Jul 2002, Julian Elischer wrote: > there are two proposals floatingat the moment.. > > 1/ I added debugging stuff to TAILQ to help find bad usages in KSE. > Qusetion/proposal: Should I extend this to other types and add it to the > file (or not delete what is there now) I was suggesting that you add macros for debugging purposes instead of potentially changing existing behaviour. The way you've got it now is OK I guess, just as long as it somehow doesn't get enabled or changed in userland. Perhaps it would even break consumers of it in the kernel, though, too. > 2/ > We could add a new macro/method that is slightly less efficient than the > current FOREACH macros, but allows element removal. > Exisiting methods would no change. As wollman pointed out, we already assume that it is safe to remove elements using the existing macros. Adding another interface to do the same thing kinda imples that existing behaviour may change. As proposed though, the new macros would not only allow removals, but also modification of the removed element while still walking the list. These might be useful. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10207041414510.17696-100000>