On 9/27/06, Jason Thorpe <thorpej@shagadelic.org> wrote:
>
> On Sep 4, 2006, at 12:49 PM, David Laight wrote:
>
> > On Mon, Sep 04, 2006 at 01:34:39PM +0200, Martin Husemann wrote:
> >>
> >> But wedges have no inherent corelation to some on-disk partition
> >> format,
> >> like the disklabel which the old partition code used.
> >
> > Unfortunately this sucks realtime....
> >
> > There is nothing (to my knowledge) to ensure that the 'wedge numbers'
> > stay anything like consistent across reboots.
> > So add a 'partition' to an MBR disk, and when you reboot all the
> > numbers
> > will change.
>
> ...and this is different from USB (or Firewire or FibreChannel) how?
>
> We already have this problem, wedges doesn't really make it any
> worse.  So we will address the problem in a way that works for
> everything.  Some ideas:
>
> - Persistent volume identifiers that you can use to specify the volume
> to mount (because you REALLY care about the volume, not the device it
> happens to be on at the moment, right?)
>
> - A devfs implementation whereby the wedge code can construct symbolic
> links to the /dev/dkN entries based on volume or partition naming
> information (constructed perhaps from the 4.4BSD "pack label" +
> partition letter or maybe the GPT "partition name").
>
> > I'm also not at all sure how the boot code is meant to locate the
> > correct
> > root filesystem.
>
> that's easy -- and it already exists in the kernel.
>


I'm definitely talking a little over my head right now, but if putting
together devfs for this is too much of a barrier, would something akin
to solaris's /etc/path_to_inst be easier?

It's basically a file that defines which hardware gets called what (my
bge0 is at /rawdevices/pci1,network/0).  If you cached usb disks in
there, they would always come back to the same place until you ran a
tool to clear that cache (devfsadm on solaris) and re-scan all the
hardware.  This would also allow easy re-ordering of things like
network cards through probe-ordering and the like.