Date: Tue, 08 May 2012 10:14:43 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool Message-ID: <4FA8C7E3.8070006@FreeBSD.org> In-Reply-To: <201205071343.45955.jhb@freebsd.org> References: <4F8999D2.1080902@FreeBSD.org> <201205070953.04032.jhb@freebsd.org> <4FA7E069.8020208@FreeBSD.org> <201205071343.45955.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 07/05/2012 20:43 John Baldwin said the following: > On Monday, May 07, 2012 10:47:05 am Andriy Gapon wrote: >> on 07/05/2012 16:53 John Baldwin said the following: [snip] >> What do you think about the -LOCORE- change that Bruce inspired? > > In general I think this looks good. I have only one suggestion. In other > code (e.g. the genassym constants in the kernel) where we define constants > for field offsets, we make the constant be the uppercase name of the field > itself (e.g. TD_PCB for offsetof(struct thread, td_pcb)). I would rather > do that here as well. In this case the field names do not have a prefix, > but let's just use a BA_ prefix for members of 'bootargs'. BI_SIZE is > already correct, but this would mean renaming HT_OFF to BA_HOWTO, BF_OFF to > BA_BOOTFLAGS, and BI_OFF to BA_BOOTINFO. OK, doing this. > I think you can probably leave BA_SIZE as-is. I see that i386 genassym has a few different styles for sizeof constants: ABBRSIZE FULL_NAME_SIZE ABBR_SIZEOF FULL_NAME_SIZE looked the most appealing to me (and seems to be the most common), so I decided to change BA_SIZE to BOOTARGS_SIZE. I hope that this makes sense and I am not starting a bikeshed :-) >>> Also, at some point we could use a genassym.c file ala the kernel builds to generate >>> some of the constants in bootargs.h instead (e.g. the offsets of fields within >>> structures, and BA_SIZE, though we probably want to ensure that BA_SIZE never >>> changes). >> >> The genassym approach sounds good, but, indeed - later :) > > Yes, that can wait. I think it would not be very hard to do however. All > you really need is access to sys/kern/genassym.sh and nm. > -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FA8C7E3.8070006>