From owner-freebsd-current Wed Jan 27 19:01:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA25784 for freebsd-current-outgoing; Wed, 27 Jan 1999 19:01:52 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25771 for ; Wed, 27 Jan 1999 19:01:43 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id OAA25274; Thu, 28 Jan 1999 14:01:40 +1100 Date: Thu, 28 Jan 1999 14:01:40 +1100 From: Bruce Evans Message-Id: <199901280301.OAA25274@godzilla.zeta.org.au> To: current@FreeBSD.ORG, dillon@apollo.backplane.com Subject: Re: Changing bzero, bcopy, memset, memcpy, etc... prototypes Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I would like to propose changing the prototype for the kernel memory > zeroing and copying routines. > > Basically, the problem is that a whole hellofalot of drivers run > bzero and bcopy on volatile memory. The only way to remove the > warnings is to volatilize bzero and bcopy. No. bzero() and bcopy() are for handling ordinary memory. There is no proper way to volatilize them without pessimizing them. Adding volatile to their prototypes won't actually make them handle volatile memory; it just breaks the warnings. Some of the i586-optimized versions in fact don't handle volatile memory properly - they do things like reading some locations twice to prefetch the cache lines. Even ordinary bcopy() via movsl accesses memory backwards in some cases. Drivers should use the bus access macros. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message