Re: cross compile gnumach and hurd
> FreeBSD can make ufs partitions, and I believe the Hurd can run on
> them, although I have only tried accessing ufs partitions from the
> Hurd, not booting the Hurd from them.
The Hurd uses a ufs format that is mostly compatible with BSD, though I am
not sure that the Hurd does the right thing with the newest BSD ufs format
details if they have changed in recent years (it works with original 4.3BSD
and 4.4BSD formats).
> I have wondered how the Hurd handles passive translators on ufs
> partitions, as ext2fs needs to be created with the -O hurd option
> in order for passive translators to work.
The need for this is so that e2fsck will know about the translator blocks.
The situation is similar in ufs, but no BSD fsck that I know of knows to
check for the Hurd's translator blocks. For both ufs and ext2fs, the Hurd
uses the traditional format except for a couple of new inode fields (which
occupy space that was unused in the traditional inode formats). The only
one of these that involves any hair is the translator field: the Hurd
allocates a disk block to hold a passive translator setting, and stores
this block number in the inode's translator field. If fsck does not know
about this field, it will decide that the block was not really in use and
it will mark it for reuse (you will see a complaint "salvaging unused
blocks not in allocation bitmap" or something along those lines). In the
case of ext2fs, e2fsck checks the "creator os" field in the superblock
(this is what "mke2fs -o hurd" sets) and when it's set to the hurd value it
knows about the translator inode field and does the right thing. In the
case of ufs, you need to use the Hurd's native fsck since that is the only
implementation around that knows about the translator field (it would be
easy to hack any current BSD system's fsck to grok it).
Reply to: