Skip site navigation (1)Skip section navigation (2)
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>