...so what ever came of this conversation?  I'd hate to see it die.  Can
we agree that a unified disktab would be best?  I hate to keep mentioning
them, but I see FreeBSD basically uses it for two purposes now:  1) Really
old fixed disks (conner, etc), and removable media (ls120, z100, etc.)

I guess the big question remains: how to overcome ufs slice boundry
defintions on different platforms.

On Tue, 27 Nov 2001, Brian A. Seklecki wrote:

>
> 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"
>
>

--Brian

 ----

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