Date: Fri, 25 Oct 2002 10:44:16 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Mark Valentine <mark@thuvia.demon.co.uk> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Takahashi Yoshihiro <nyan@jp.FreeBSD.org>, bde@zeta.org.au, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Message-ID: <200210251744.NAA24610@tonnant.cnchost.com> In-Reply-To: Your message of "Fri, 25 Oct 2002 13:16:19 BST." <200210251216.g9PCGJtO068434@dotar.thuvia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >/dev/motherboard/pcibus/0/pcib/0/pci/0/7/0/ahc/0/0/0/0/da/0/4/a/kernel,
> > >anyone? :-)
There is always one wiseguy....:-)
> Seriously, though, there are merits to something like the Solaris /devices
> and /dev distinction between physical and logical device names (though they
> still kept the SysV brain damaged /dev names).
IMHO devfs could've automagically built /devices, not /dev.
What with USB and all, the actual controller/device tree can
be pretty dynamic and best discovered automatically. [Aside:
is anyone looking at iSCSI, serial ATA etc.?]
/dev is still needed and can be built somewhat more
intelligently. If each disk had its own unique id (like what
each CD has), moving disks around would change /devices but
/dev can still look the same. Something like
/dev/da0a -> <unique-id> -> /devices/ahc0/bus0/target0/lun0/...
Something in the system will have to keep track of the
/dev/<disk> to unique id mapping. In general any device that
can be uniquely identified can be handled this way.
This scheme is not perfect either -- how do you ensure unique
ids? What do you do when an exact copy disk is attached?
etc.
My point is this: if you are going to fix the system, don't
make many mickey-mouse changes that may break compatibility
and encourage endless debates. Instead think things through,
learn from what previous systems have done, look at usage
patterns, changes in them, look at future directions and then
come up with a coherent design (may be even a total revamp!)
and *provide backward compatibility (if at all possible) and
tools for upgrading*. Not exactly a JKH task.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210251744.NAA24610>