Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Apr 1997 20:17:05 -0800
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        Terry Lambert <terry@lambert.org>
Cc:        nate@mt.sri.com (Nate Williams), proff@suburbia.net, hackers@FreeBSD.ORG
Subject:   Re: Internal clock 
Message-ID:  <28836.859954625@time.cdrom.com>
In-Reply-To: Your message of "Tue, 01 Apr 1997 16:55:20 MST." <199704012355.QAA12469@phaeton.artisoft.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> We *have* a well designed and thought out device interface: devfs.

Well thought-out, yes.  Finished, no. :)

> I have *no* idea what is preventing you from making it the default
> mechanism.

1. It has no persistance and a number of people have already told me directly
   (some of them at USENIX, immediately following Julian's talk on DEVFS)
   that we will be roundly castigated and screamed at in the various
   public forums for breaking /dev's historical behavior if we don't make
   persistance work and work *completely transparently*.  Let's say
   somebody has a "securify" script that they run on a new system as part
   of their security auditing process.  It's been running on FreeBSD
   systems since 2.0, making sure that tape drives and CDROMs and such
   all have sane perms (or maybe even some sort of "insane" perms which are
   part of a more elaborate ownership scheme which they like), and now
   suddenly with FreeBSD 4.0 or whatever they find that everything the
   script does on these new systems is undone after a reboot.  Say what??

   Sure, one can stick something in /etc/rc.local which does everything
   from beating on /dev to translating the catpages into Urdu, but
   the fact remains that someone shouldn't need to do that.  As you yourself
   say, things should stay *backwards compatible*. :-)

2. It tends to panic the system fairly regularly on steady use.  Why on
   earth would we make something this dangerous the default?  It's
   simply not finished yet, and there are numerous open PRs against it in
   the PR database (#2033, #2034, #2738 and possibly #1211).

						Jordan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28836.859954625>