Re: DISKLABEL_EI option for system with MBR

[Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>]

Thank you very much for your comments.

On 2017/02/12 12:06, Paul Goyette wrote:
> I don't really have any objections, but I would like to clarify the scope of what is being proposed.
>
> 1. Does this allow only processing of disk labels that are (a) already
>    written in opposite-endian format?  Or does it also (b) provide a
>    mechanism to write _new_ labels in opposite-endian format, too?
>
>    If the answer is (a), is this sufficient?  Or would (b) be a
>    desirable feature?

Neither (a) nor (b). With ioctls, new labels are written in the native
byte order. When we update labels, their byte order is kept. We can
write labels in any byte order by using -F option for disklabel(8)
(bypass ioctls and treat disks as regular files) combined with "-B le"
or "-B be" options.

> 2. Does this affect (c) only the disklabel(8) stuff?  Or does it also
>    (d) affect the MBR itself (the stuff handled by fdisk(8))?
>
>    Again, is (c) sufficient, or should we also do (d)?

The answer is (c). MBR stuff is always written in little endian.

> 3. Do wedges still work?  Does the patch allow opposite-endian for
>    the wedge configuration data?

This patch does not take special care of wedges. I don't know much of
wedges, but opposite-endian for the wedge configuration data should
be supported by sys/dev/dkwedge if needed.

> And a couple of side questions:
>
> 4. Where on the physical device is the wedge configuration saved,
>    anyway?)

Sorry, I don't know.

> 5. Does the current FFS_EI allow for creation of opposite-endian
>    file systems?  I don't see any endian option for newfs(8).

We can use "newfs -B le" or "newfs -B be".

I would appreciate if someone could give comments on wedges.

Thanks,
rin