Subject: Re: CVS commit: src/sys/arch/x86/x86
To: Christos Zoulas <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 08/14/2006 15:12:04
On Aug 14, 2006, at 12:55 PM, Christos Zoulas wrote:
> 1. How did you plan to deal with bsize,fsize,cpg info that used to
> be stored in the disklabel in the wedge world?
I don't. Those can't be represented in most of the world's partition
types. If anything depends on them, then those things need to be
moved into the superblock of the corresponding file system -- they are
FILE SYSTEM parameters, after all, and don't belong in the partition
> 2. Do you have newfs/fsck/dump working with wedges?
I have some preliminary stuff. Note I had a system running completely
on wedges before I had to pack up my stuff to move to a new house last
year. This included fsck-at-boot.
> 3. What's the plan to convert existing disk drivers to use wedges,
> and moving the bulk of the old partitioning code to one place?
Plan isn't fully-formed yet. We need universal wedge support first,
so we can deprecate the old driver entry points.
> 4. How is userland supposed to get geometry information now?
It will use a new ioctl that will return a dictionary that has disk
info, including geometry. I'm still working on that stuff (along with
a library that will take a "partition info" dictionary and convert it
into the selected on-disk format).
> 5. Are we planning to be able to mount by wedge name?
Yes, the goal is to be able to identify a device-to-mount by wedge
name or other persistent identifier that is independent of probe order
(e.g. partition GUID).
> 6. Are we going to have GPT NetBSD GUIDs? What is the list of GUIDs
> that we would need? How to generate them?
I don't see any reason not to leverage extant GUIDs for partition
types that are out there in the world already (e.g. the FAT types,
EXT2, etc.). What to do about FFS and FreeBSD's GUID for that is
still up in the air -- there may be value in distinguishing between
theirs and ours.
That's a discussion I planned on having later.