Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Sep 1997 16:42:25 +1000
From:      Stephen McKay <syssgm@dtir.qld.gov.au>
To:        Paul Traina <pst@shockwave.com>
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 
Message-ID:  <199709150642.QAA13332@ogre.dtir.qld.gov.au>
In-Reply-To: <199709150038.RAA13043@precipice.shockwave.com> from Paul Traina at "Mon, 15 Sep 1997 00:38:06 %2B0000"
References:  <199709150038.RAA13043@precipice.shockwave.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



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