Greetings and Revelations!

>Brian Seklecki, throwing his arms skyward, exclaimed:

>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


Hmmm, I guess it depends on what you are talking about:

#        $NetBSD: csh.cshrc,v 1.2 1996/05/08 17:19:27 thorpej Exp $
#        $NetBSD: csh.login,v 1.2 1996/05/08 17:19:28 thorpej Exp $
#       $NetBSD: csh.logout,v 1.2 1996/05/08 17:19:31 thorpej Exp $
#    $NetBSD: daily,v 1.33.2.1 2000/08/25 03:05:19 hubertf Exp $
#       $NetBSD: daily.conf,v 1.2.12.2 2000/10/02 03:15:38 lukem Exp $
#  $NetBSD: disktab,v 1.10 2000/05/31 17:39:55 matt Exp $
#  $NetBSD: dm.conf,v 1.3 1997/02/15 10:02:12 mikel Exp $
#        $NetBSD: floppytab,v 1.1 1996/11/29 16:31:54 jtk Exp $
# $NetBSD: fstab.sd,v 1.3 1998/01/09 06:09:44 perry Exp $
#        $NetBSD: ftpchroot,v 1.3 1997/01/04 14:03:34 mrg Exp $
# $NetBSD: ftpusers,v 1.4 1997/09/08 02:51:58 mikel Exp $
# $NetBSD: gettytab,v 1.15 1999/12/15 17:34:00 drochner Exp $
#       $NetBSD: inetd.conf,v 1.35.2.5 2001/04/06 00:40:59 he Exp $
# $NetBSD: lkm.conf,v 1.2 1997/07/14 11:55:46 drochner Exp $
#      $NetBSD: mailer.conf,v 1.2.10.1 2000/07/26 17:17:14 itojun Exp $
# $NetBSD: man.conf,v 1.18.4.1 2000/08/01 13:40:11 chuck Exp $
#  $NetBSD: monthly,v 1.8 2000/01/10 17:03:49 ad Exp $
#     $NetBSD: monthly.conf,v 1.1.12.2 2000/10/02 03:28:51 lukem Exp $
#     $NetBSD: mrouted.conf,v 1.4 1996/12/29 03:30:10 mrg Exp $
# $NetBSD: netconfig,v 1.1 2000/06/02 22:54:10 fvdl Exp $
# $NetBSD: networks,v 1.5 1998/07/10 06:22:15 fair Exp $
#   $NetBSD: newsyslog.conf,v 1.13 1999/11/30 12:03:26 ad Exp $
#    $NetBSD: nsswitch.conf,v 1.5 1999/10/24 12:36:52 lukem Exp $
# $NetBSD: ntp.conf,v 1.2 2000/05/02 12:16:07 simonb Exp $
#   $NetBSD: phones,v 1.4 1997/02/15 10:02:21 mikel Exp $
#  $NetBSD: profile,v 1.1 1997/06/21 06:07:39 mikel Exp $
#        $NetBSD: protocols,v 1.9 2000/01/17 16:39:37 itojun Exp $
#      $NetBSD: rbootd.conf,v 1.3 1996/12/29 03:30:09 mrg Exp $
# $NetBSD: rc,v 1.152.4.1 2000/08/23 12:05:17 lukem Exp $
#   $NetBSD: rc.lkm,v 1.5 2000/05/26 17:46:16 tron Exp $
# $NetBSD: rc.local,v 1.25.10.2 2000/10/07 20:21:35 hubertf Exp $
# $NetBSD: rc.shutdown,v 1.3.4.1 2000/08/09 18:39:38 lukem Exp $
# $NetBSD: rc.subr,v 1.20.2.4 2000/10/02 01:02:49 lukem Exp $
#   $NetBSD: remote,v 1.7 1997/04/24 00:35:47 mellon Exp $
#      $NetBSD: rpc,v 1.6 2000/06/02 22:54:10 fvdl Exp $
#      $NetBSD: rtadvd.conf,v 1.4 2000/03/17 17:35:20 itojun Exp $
# $NetBSD: security,v 1.44.4.1 2000/07/03 02:27:20 sommerfeld Exp $
#    $NetBSD: security.conf,v 1.5.4.2 2000/10/02 03:29:56 lukem Exp $
#   $NetBSD: shells,v 1.3 1996/12/29 03:23:07 mrg Exp $
# $NetBSD: sysctl.conf,v 1.3 2000/04/15 21:14:49 tsarna Exp $
#   $NetBSD: weekly,v 1.14 2000/01/10 17:03:49 ad Exp $
#      $NetBSD: weekly.conf,v 1.1.12.2 2000/10/02 03:28:51 lukem Exp $

None of *these* have been updated in similar or LONGER times...  :>
By my count, some 40+ "old" files out of the 100 or so in /etc
(not counting subdirectories).  "Static" doesn't mean "useless"  :>

Note that *my* post was an attempt to update disktab(5) -- so
*some* folks are willing to undertake *some* effort to keep
adding entries...

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


Is it any less realistic than maintaining a termcap or modemcap
(or printcap, etc.) database?  It's not like these things
*change*.  Create an entry for an RK01 and leave it there...
no "work" involved "updating" *that* entry -- far more work
trying to find one of the things that still *works*!!  :>

I don't understand the need for them on a per architecture
basis, though.  But, I confess I haven't gone peeking through 
them to try to understand "why"...  <:-(

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


I would like someone to clarify why we can't have The One True
Disktab -- instead of different flavors.  Can all of them be merged
into one "database"?  Can removing the slice/partition information
then help consolidate this?

Again, it's just a convenient repository for this sort of
information.  Just because a particular architecture/port might
not support a particular type of drive (e.g., IDE on an Apple?),
doesn't mean the entries can't occupy space in the file!
SPARC doesn't support wscons yet there are files and mechanisms
taking up space on the disk that are solely related to this.
Man pages are shipped for "all" architectures even though a 
particular host only runs as *one* architecture, etc.

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


It was my contention that "slices" (nee partitions) should be
dropped from the entries.  It seems to be highly subjective
any way you cut it.  Unless there was some oddball drive
that *imposed* some sort of limits on the slices/partitions...
I suspect that is a throwback to the days when disktab was used
to create disklabels.

If there is some rationale/concensus on the issue, I can take
a quick jaunt through the files and see how well it could
be condensed...

--don