Re: [PATCH 2.6.15] ufs cleanup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Fri, 13 Jan 2006, Evgeniy wrote:
> +static inline struct ufs_super_block_second *
> +ubh_get_usb_second(struct ufs_sb_private_info *uspi)
> +{
> +	char *res=uspi->s_ubh.bh[UFS_SECTOR_SIZE >> uspi->s_fshift]->b_data + 
> +		(UFS_SECTOR_SIZE & ~uspi->s_fmask);
> +	return (struct ufs_super_block_second *)res;
> +}

I was thinking of something even more abstracted:

	static inline void *get_usb_offset(struct ufs_sb_private_info *uspi,
		unsigned int offset)
	{
		unsigned int index;

		index = offset >> uspi->s_fshift;
		offset &= ~uspi->s_fmask;
		return uspi->s_ubh.bh[index]->b_data + offset;
	}

and then just doing

	#define ubs_get_usb_first(uspi) \
		((struct ufs_super_block_first *)get_usb_offset(uspi, 0))

	#define ubh_get_usb_second(uspi) \
		((struct ufs_super_block_second *)get_usb_offset(uspi, UFS_SECTOR_SIZE))

	#define ubh_get_usb_third(uspi) \
		((struct ufs_super_block_third *)get_usb_offset(uspi, 2*UFS_SECTOR_SIZE))

or something similar. Which seems a hell of a lot more readable to me, and 
assuming it passes testing (ie I didn't screw up), I think it's more 
likely to stay correct in the future and just generally be maintainable.

Hmm?

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux