From owner-cvs-lib  Mon Sep 15 11:20:19 1997
Return-Path: <owner-cvs-lib>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id LAA14597
          for cvs-lib-outgoing; Mon, 15 Sep 1997 11:20:19 -0700 (PDT)
Received: from precipice.shockwave.com (precipice.shockwave.com [207.105.15.229])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14586;
          Mon, 15 Sep 1997 11:20:13 -0700 (PDT)
Received: from shockwave.com (localhost [127.0.0.1]) by precipice.shockwave.com (8.8.6/8.7.3) with ESMTP id LAA14943; Mon, 15 Sep 1997 11:17:16 -0700 (PDT)
Message-Id: <199709151817.LAA14943@precipice.shockwave.com>
To: Stephen McKay <syssgm@dtir.qld.gov.au>
cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-lib@FreeBSD.ORG
Subject: Re: cvs commit: src/lib/libc/gen getpwent.c 
In-reply-to: Your message of "Mon, 15 Sep 1997 16:42:25 +1000."
             <199709150642.QAA13332@ogre.dtir.qld.gov.au> 
Date: Mon, 15 Sep 1997 11:17:16 -0700
From: Paul Traina <pst@shockwave.com>
Sender: owner-cvs-lib@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Let me posit the reverse, -current's stability is always questionable.

If I build a new kernel, then build userland, install new kernel, then
find new kernel is suboptimal, what do I do?

  From: Stephen McKay <syssgm@dtir.qld.gov.au>
  Subject: Re: cvs commit: src/lib/libc/gen getpwent.c 
  On Monday, 15th September 1997, Paul Traina wrote:
  
  >It seems to me that we want the ability to have libc work with older
  >kernels?  If so, something along the lines of what peter did with poll()
  >in the resolver code would be correct, yes?
  
  This gives me a bit of a queasy feeling.  I have had no trouble with building
  a kernel first.  You can test boot it, and leave it to one side as you build
  the userland stuff.  Worst case, you get your secondary FreeBSD box to build
  you a new kernel.
  
  The trick with dynamically picking poll vs select is cute, but a dangerous
  precedent.  If this gets popular, it should be a library routine with
  the same arguments as poll(), but which drops back to select() if necessary.
  
  After all, userland code using poll() will be widespread only when a new
  release supporting kernel poll() is made.  At that point the hack becomes
  irrelevant.  Indeed, I like the idea of making poll() into a library call
  which dynamically calls the poll system call or select system call when
  compiled with some /etc/make.conf flag (maybe POLL_SELECT_COMPAT).  Without
  the special flag, poll would just be poll.  Only developers would set
  POLL_SELECT_COMPAT, and only for a transition period.
  
  Seems much neater to me, and puts the developer-saving hack into everything.
  
  Stephen.
  
  PS As an aside, I'm puzzled that poll is implemented exactly like System V
  with regards to the timeout parameter.  We are moving to ever more precise
  time quantities, so I would have expected a sort of super-poll taking a
  timeval or timespec, with poll() as a small library wrapper that accepts
  the timeout in ms.  I suppose there is nothing stopping us adding that
  later, but now would have been as good a time as any.