Date: Wed, 10 May 95 17:52:54 MDT From: terry@cs.weber.edu (Terry Lambert) To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Cc: imp@village.org, hackers@FreeBSD.org Subject: Re: question on sun cds Message-ID: <9505102352.AA27802@cs.weber.edu> In-Reply-To: <199505102312.QAA08704@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 10, 95 04:12:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Greetings, > > I have a need, from time to time, to read SunOS ufs formatted > > cds. These are from both SunOS 4.1.x and SunOS 5.x, aka Solaris. Is > > there something I've overlooked in FreeBSD 2.0R (or -current or 2.0.5) > > that will allow me to do this, ideally as a normal file system? > > No, you have not over looked anything. There is a fundemental problem > that makes this very hard to do. Can you say BIG_INDIAN vs LITTLE_INDIAN. > > I thought so.... Actually, for everything but the block offset calculations, the numbers are little other than tokens that get replaced in core by vnode addresses anyway. The big buggaboo is the volume label and directory entry structure differences that SunOS has. The zeroed inode number as a tag for an empty file system block is "different" in the directory entries themselves. Given the structure of the ffs/ufs division right now, I'd think you could share almost all the code except a block lookup function, which would add a function dereference overhead on block references (and another for direct inode lookups). You could get around that by pushing the two or three other ufs references into the ffs layer and making an endian-specific ffs layer for both. The overhead of a function pointer dereference compared to the layering abstraction itself as it currently sits isn't significant enough that I'd really worry about it anyway. I think it's just noise, since most of the block can come from the cache and you can use the inverted values as cache tags so no conversion is necessary for hits. > > Baring functional code, anybody have any ideas on how to procede? > > Major reworking of the ufs layer to do INDIAN conversion based on > volume label magic values. Can you say slow ufs after you do this? I'd say only a teeny bit slower FFS after this. The big buggaboo, like I said, is the volume label, and that's mostly clean bit handling and a couple of stamps for file system events that it'd be pretty easy to deal with. If you were trying to write a FS for a Solaris box instead, that'd be a much bigger pain (it'd have to be kernel preeemption safe and Sun did it the wrong way, IMO). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505102352.AA27802>