Date: Tue, 26 Aug 2003 01:20:35 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/gnu/ext2fs ext2_bitops.h ext2_linux_balloc.c ext2_linux_ialloc.c ia64-bitops.h Message-ID: <20030826082035.GA728@dhcp43.pn.xcllnt.net> In-Reply-To: <20030826172816.E9176@gamplex.bde.org> References: <200308250139.h7P1dlwg002331@repoman.freebsd.org> <20030826172816.E9176@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 26, 2003 at 05:44:40PM +1000, Bruce Evans wrote: > On Sun, 24 Aug 2003, Marcel Moolenaar wrote: > > > marcel 2003/08/24 18:39:47 PDT > > > > FreeBSD src repository > > > > Modified files: > > sys/gnu/ext2fs ext2_linux_balloc.c ext2_linux_ialloc.c > > Added files: > > sys/gnu/ext2fs ext2_bitops.h > > Removed files: > > sys/gnu/ext2fs ia64-bitops.h > > Log: > > Change of plans: Add ext2_bitops.h with generic and portable > > implementations. Use those on platforms that don't have MD > > headers. Remove the ia64 MD header. We're going to use the C > > implementation there. > > > > Suggested by: bde > > Thnaks. I'll deventually do some benchmarks to see if we want the MD > (inline assembler) versions at all. Ok. I didn't write the functions for speed so there may be some opportunities after analyzing what the compiler made of it. BTW: I noticed that GCC has a builtin implementation for ffs(). It may be beneficial. > Technical questions: > - Do you really need the locking (atomic_cmpset)? I think there should > be higher level locking in the context of ext2fs. The purpose of the inline functions as explained by the comments is to provide fast and atomic behaviour. I didn't question this or verified that such was actually necessary. If we already serialize access to the data structures of which the bit string is a member, then atomicity obviously only costs us. > - The sparc64 versions seem to show need for complications in endian > mismatch cases. I think ext2fs is always little endian. For bitmaps, > getting a free bit from the wrong end might only be a pessizimation. Good point. I saw that there was a sparc64 specific header for bitops, so I didn't worry about that. Although not seeing it included in the source files should have given me the hint. It's probably sufficient to use le32toh and htole32 when we read from and write to (resp) the bit string. On little-endian machines this is a no-op anyway. All other operations are register based, so there should be no problem. Feel free to make any necessary changes. No need to have me review it. I don't know anything about ext2fs anyway :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030826082035.GA728>