Date: Mon, 15 Sep 1997 11:17:16 -0700 From: Paul Traina <pst@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 Message-ID: <199709151817.LAA14943@precipice.shockwave.com> In-Reply-To: Your message of "Mon, 15 Sep 1997 16:42:25 %2B1000." <199709150642.QAA13332@ogre.dtir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709151817.LAA14943>