Okay, I see it now:

http://cvsweb.netbsd.org/bsdweb.cgi/basesrc/etc/etc.sparc/disktab
http://cvsweb.netbsd.org/bsdweb.cgi/basesrc/etc/etc.i386/disktab

	The former hasn't been updated in 17 months, the latter in 2
years!  That's _bad_ for files in /etc

	What I'm getting at is the redundancy of attempting to maintain a database
of fixed disks model and geometry's on a per vendor/model basis, and then
on top of that, we're maintaining separate ones on a per - architecture
basis.

	Perhaps disktab(5) would be best utilized for removable media,
like floppies, zips, and optical media.  Then we could maintain a
architecture - independent one.

	The problem of course, with that idea, is the indexing of slices
(o[a-h] , p[a-h], b[a-h],etc.).  For example, I'm accustomed to using
slice "d:"  as a slice on sparc, but that's reserved in i386 for the "DOS
partition", etc.

--Brian

 ----

"GNU/Linux: About as stable as the elements at the bottom of the periodic
table"