From owner-cvs-lib Sun Sep 14 23:45:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA05530 for cvs-lib-outgoing; Sun, 14 Sep 1997 23:45:11 -0700 (PDT) Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA05490; Sun, 14 Sep 1997 23:44:50 -0700 (PDT) Received: (from daemon@localhost) by bunyip.cc.uq.edu.au (8.8.7/8.8.7) id QAA03666; Mon, 15 Sep 1997 16:43:34 +1000 Received: from localhost.dtir.qld.gov.au by ogre.dtir.qld.gov.au (8.7.5/DEVETIR-E0.3a) with SMTP id QAA13332; Mon, 15 Sep 1997 16:42:26 +1000 (EST) Message-Id: <199709150642.QAA13332@ogre.dtir.qld.gov.au> To: Paul Traina cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-lib@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: cvs commit: src/lib/libc/gen getpwent.c References: <199709150038.RAA13043@precipice.shockwave.com> In-Reply-To: <199709150038.RAA13043@precipice.shockwave.com> from Paul Traina at "Mon, 15 Sep 1997 00:38:06 +0000" Date: Mon, 15 Sep 1997 16:42:25 +1000 From: Stephen McKay Sender: owner-cvs-lib@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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.