Re: CVS commit: src/etc/mtree

2011-09-07 Thread David Laight
On Wed, Sep 07, 2011 at 08:13:20AM +, David Holland wrote: > > The fundamental problem is that the make library finds files by > implicit path searches (of various kinds) which is inherently wobbly > no matter how many bandaids are applied. Especially in large items like libc andthe kernel...

Re: CVS commit: src/share/man/man4

2011-09-07 Thread Joerg Sonnenberger
On Wed, Sep 07, 2011 at 01:05:18PM +0300, Jukka Ruohonen wrote: > > The fact that Linux has always done this wrong is not a reason to go > > chasing after them and reinventing their mistakes. > > As usual, you managed to marvellously miss the point. The reason Linux does > this (right) is the amou

Re: CVS commit: src/share/man/man4

2011-09-07 Thread Jukka Ruohonen
On Wed, Sep 07, 2011 at 09:24:22AM +, David Holland wrote: > The purpose of GENERIC is (and has been since before Linux was > invented) to include all drivers and features that can reasonably be > expected to work. Drivers and other code that are commented out in > GENERIC (or not present at al

Re: CVS commit: src/share/man/man4

2011-09-07 Thread David Holland
On Tue, Aug 30, 2011 at 07:44:17PM +0300, Jukka Ruohonen wrote: > > And why should GENERIC *not* support hardware that is available, works, > > and is of use to someone? If GENERIC is to support only the idea of > > what an OS should look for some developers, why do we ship GENERIC at > > all

Re: CVS commit: src/etc/mtree

2011-09-07 Thread David Holland
On Tue, Sep 06, 2011 at 02:53:58PM +0400, Valeriy E. Ushakov wrote: > Are you saying you are going to add a special case for each foo.o file > each time an accidental non-objdir build left foo.o in src? (and no, > that's not a rhetoric question). The fundamental problem is that the make library

Re: CVS commit: src/usr.bin/touch

2011-09-07 Thread David Holland
On Tue, Sep 06, 2011 at 11:59:50PM +0400, Valeriy E. Ushakov wrote: > > Please commit changes like the following together instead of spamming > > the source-changes list. > > I don't think that "spamming" source-changes is a very high priority > consideration. OTOH, I know that per-directory