Date: Fri, 25 Oct 2002 15:44:36 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Dan Nelson <dnelson@allantgroup.com> Cc: Julian Elischer <julian@elischer.org>, Mark Valentine <mark@thuvia.demon.co.uk>, Poul-Henning Kamp <phk@critter.freebsd.dk>, "M. Warner Losh" <imp@bsdimp.com>, freebsd-arch@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: <Pine.NEB.3.96L.1021025154115.58150G-100000@fledge.watson.org> In-Reply-To: <20021025193859.GA51818@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 25 Oct 2002, Dan Nelson wrote: > In the last episode (Oct 25), Julian Elischer said: > > <dreaming> > > In the future I feel that the default names may eventually be > > over-ridden by semantically meaningfull names. e.g. You may partition a > > drive and give each partition a name which might be used instead of the > > default inherrited name.. e.g. ad0s1s2b (not a typo) may decide that it > > would rather be known "/dev/swap2" because the table entry has a field > > "swap%d" in it, or disk2 may decide that it wants to be known as > > "/dev/tunes". (A removable disk full of music) > > Linux allows this, sort of. You can label disks with tune2fs, and mount > can find disks based either the label or filesystem UUID. This lets you > have an fstab that looks like Gordon Tetlow and I have been discussing possibly reusing the superblock "last mounted on" field for volume label and uuid storage. Right now the "last mounted on" data is basically used for printfs, and often somewhat confusingly (the kernel will print the last mount point when reporting a mount error, which might not be where the user is trying to mount). It's 512 bytes of superblock space, so would provide lots of room for volume identifier information, if we decided to go that way. Anyone interested in this sort of thing should spend a fair amount of time looking at prior art, including at Apple's approach to volume name automounting. Also, Poul-Henning's comments on security are important: in some case, you may be less willing to trust the label on the media than others. Another important consideration relates to issues like removable media, and media from less trusted sources, as well as accidental collisions in the namespace. If anyone wants to take on this project seriously, GEOM and devfs provide a good starting point and many of the tools you need. Anyone giving it a try should go do a prior art search and document what they find, however. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021025154115.58150G-100000>