On Tuesday, April 19, 2011 2:04:53 pm Warner Losh wrote: > > On Apr 19, 2011, at 6:40 AM, John Baldwin wrote: > > > On Monday, April 18, 2011 3:59:45 pm Warner Losh wrote: > >> > >> On Apr 18, 2011, at 12:18 PM, Doug Barton wrote: > >> > >>> On 04/18/2011 11:14, Pawel Jakub Dawidek wrote: > >>>> On Mon, Apr 18, 2011 at 11:06:42AM -0600, Warner Losh wrote: > >>>>> > >>>>> On Apr 18, 2011, at 1:01 AM, Roman Divacky wrote: > >>>>> > >>>>>> please mark this in src/UPDATING, maybe bump freebsd_version too? > >>>>> > >>>>> Please do not bump freebsd_version just for this. Ports wishing to > >>>>> know > > can go off the last bump, if there are any. > >>>>> > >>>>> Every freebsd_version bump forces rebuilding all modules and such and > >>>>> is > > a pita. > >>>> > >>>> I agree that this is a PITA, but there also should be a way to force > >>>> module load even on version bump. This is PITA especially for > >>>> developers. > >>> > >>> .... who make up a tiny percentage of the FreeBSD user community. > > Seriously? We're going to whine because version bumps cause a little extra > > compile time? > >> > >> The problem usually manifests itself when I got to debug a new problem, > >> load > > a driver and find I have to rebuild everything else to use it, which forces > > an > > extra reboot on the machine in question. Sometimes this can be quite > > disruptive to other things that machine is doing. > > > > But that is only true if your source tree doesn't match your installed > > world. > > If the new driver is standalone and you build it as a module, it will use > > the > > headers from /sys and will work fine. > > It is rarely the case that my source matches my install world. My kernel and > userland are asynchronously updated when I'm doing heavy kernel development. My sources are updated all the time to pull in useful things that I need. When I'm in this mode, I carefully track what's changed to make sure there were no recompile the world events. When a userland thing changes that bumps freebsd_version, I have to recompile the kernel and reboot, even though there's no need to do so. This is especially annoying when it happens a few times within one week, since it is a hit to my productivity each time it happens. There's no great need to have userland features identified with the fidelity of a few dozen commits in - current. A few hundred or more would suffice for ports and those interested, so bumping more than once a week provides almost no benefit, but inflicts some pain.
Hmm, my development tree never matches my /usr/src either, but I never run into this. I always build a kernel in a p4 or whatever checkout and do 'make install KERNEL=foo' (or make installkernel INSTKERNNAME=foo) along with 'nextboot -k foo' (or 'boot foo' at the loader prompt). My current testboxes actually tend to have 7.x worlds and I just boot 9 kernels on them all the time. But by building a new kernel each time I never hit problems with __FreeBSD_version checks. However, all that said, I would have no problem having something you can set in make.conf or on the command line to disable the check for a given module build. Oh, one other thing, if you stick your module directory in a kernel tree that matches whatever the running kernel is, then that also works fine. I do this a lot where I've booted a 9.0 kernel on a 7.x machine, and then have a sys/modules/foo in that source tree and I can build the module from that directory and load/unload it without any problems. > >> In this case, there was a new kernel thing just after, so it turned out > >> OK. > > But let's not gratuitously bump the version since the granularity we have > > already allows the ports to make good choices on when to leave something in > > or > > out. > > > > Except that that directly contradicts our previously established policy > > that > > these version bumps are cheap and that we should do more of them (this came > > up > > a few years ago when we changed the policy so that the new "stable" branch > > after a release starts at N + 500 (e.g. 802500) rather than N + 100 to give > > more room for version bumps on current). > > We have never said that version bumps were totally cheap. In -current, > there's little benefit to bumping things more often than once a week. Since we generally develop stable for more than 2 years, 100 wasn't enough at the one a week rate. But that doesn't mean that 5 per week is OK either, since now we suddenly have room for them. I'm strongly suggesting that for userland-only changes that one check to see when the last bump was and if it is less than a few days (or a week), then to piggyback off the last one/next one to discriminate whether to use an old feature, or start using a new feature. Especially for retroactive bumps that happen disconnected to the original feature going in. I can't find the original thread, but we did in fact say that. :) However, I'd be happy to only have one a week or what not. Big interface changes should generally have them though, especially if they affect KPIs used by out of tree drivers or other software in ports. -- John Baldwin _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
