tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: MKPUFFS and other userspace build variables



On Tue, Dec 30, 2008 at 03:42:01PM +0200, Mikko Rapeli wrote:
> Modularity is good for user space too, so why was MKPUFFS build flag
> removed a while ago? And generally, are new build flags for userspace
> accepted or not?
>
> MKPUFFS removal probably had something to do with the MKRUMP I proposed as a
> workaround for the problems I saw and still see with rump and binutils
> 2.18.50. MKPUFFS removal of course broke the MKRUMP patch, but I have
> fixed it since I need it. Though right now MKPUFFS would be nice.
> I also have an ARM specific MKGZBOOT due to problems introduced by newer
> binutils. But I'm not sure what to do with these patches.
> 
> IMO, the build variables could exist even if they bit rot a bit and
> active maintainers don't care about them. Sometimes it is easier for us
> users to fix the broken build variable than to dig into fixing some other
> part of NetBSD which is not relevant for the work at hand. Especially current
> is such a moving target, that build variables help when reproducing
> problems with various snapshots of it which each suffer from different build 
> or
> other failures.

MKPUFFS existed because initially puffs was not considered ready
for all users.  Once this reason went away, so did the flag.  This
was documented in bsd.README.
(I would have liked to do it at the same time as the default was
flipped, but I was travelling before the 5.0 branch)

Introducing random build flags to battle transient build breakage
is pointless.  All users are free to patch their local trees to
avoid fixing issues not relevant to their current work.  I do that
too.

And, if you are referring to the dev_t change in libpuffs, MKPUFFS
would not help, since libpuffs was always built regardless.


Home | Main Index | Thread Index | Old Index