Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: "Add Partition" "size" shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: "Add Partition" "size" shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: "Add Partition" "size" shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: "size" shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: "Add Partition" "size" shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent "Create" will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
Jason Edwards writes: > Has anyone noticed the easy editor is quite bugged on 9.0? On console > direct access, opening the easy editor has several bugs: > > 1) the cursor starts on line 2 instead of line 1 > 2) the line numbering is printed on line 1 instead of the boundary (line 0) > 3) the keys page up and page down bring the escape menu Try to use cons25 emulation beforehand $ vidcontrol -T cons25 # aka TEKEN_CONS25 in kernel config unless you've updated etc/ttys to use `xterm'. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
On Sat Nov 19 11, Garrett Cooper wrote: > On Sat, Nov 19, 2011 at 12:53 PM, Alexander Best wrote: > > On Sat Nov 19 11, Garrett Cooper wrote: > >> On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd wrote: > >> > .. how many users is this going to trip up? > >> > >> cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I > >> went through several iterations with ed@ over the fact that various > >> curses based apps were broken with the libteken work, but then just > >> gave in and set 'xterm'. > >> > >> That being said, I can't reproduce the issue Jason mentioned in the first > >> post. > > > > running a very recent HEAD doing 'export TERM=cons25' in zsh and then > > running > > 'ee', i can exactly reproduce this issue. > > How are you accessing the terminal? I ask in part because of this > email thread: http://comments.gmane.org/gmane.os.freebsd.current/136528 what do you mean? i fire up xterm (actually sakura in my case) and simply type 'export TERM=cons25'. this is on my local machine. however i tried the same over ssh, connecting to hub.freebsd.org (which is running7.4-STABLE, and got the same result. cheers. alex > . > Cheers, > -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
On Sat, Nov 19, 2011 at 12:53 PM, Alexander Best wrote: > On Sat Nov 19 11, Garrett Cooper wrote: >> On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd wrote: >> > .. how many users is this going to trip up? >> >> cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I >> went through several iterations with ed@ over the fact that various >> curses based apps were broken with the libteken work, but then just >> gave in and set 'xterm'. >> >> That being said, I can't reproduce the issue Jason mentioned in the first >> post. > > running a very recent HEAD doing 'export TERM=cons25' in zsh and then running > 'ee', i can exactly reproduce this issue. How are you accessing the terminal? I ask in part because of this email thread: http://comments.gmane.org/gmane.os.freebsd.current/136528 . Cheers, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
On Sat Nov 19 11, Garrett Cooper wrote: > On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd wrote: > > .. how many users is this going to trip up? > > cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I > went through several iterations with ed@ over the fact that various > curses based apps were broken with the libteken work, but then just > gave in and set 'xterm'. > > That being said, I can't reproduce the issue Jason mentioned in the first > post. running a very recent HEAD doing 'export TERM=cons25' in zsh and then running 'ee', i can exactly reproduce this issue. cheers. alex > > 1. Have you rebuilt your termcap database? > 2. What is your $TERM in the ssh case and the console case? > Etc. > > Thanks, > -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
On Sat, Nov 19, 2011 at 11:05 AM, Adrian Chadd wrote: > .. how many users is this going to trip up? cons25 is pretty much FUBAR on 9.x+ compared to previous releases. I went through several iterations with ed@ over the fact that various curses based apps were broken with the libteken work, but then just gave in and set 'xterm'. That being said, I can't reproduce the issue Jason mentioned in the first post. 1. Have you rebuilt your termcap database? 2. What is your $TERM in the ssh case and the console case? Etc. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
.. how many users is this going to trip up? adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [Sbcl-bugs] crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread
Nikodemus Siivola writes: >> After r216641 sbcl built with sb-thread dies on mailbox tests. It also >> dies when I try to complete a symbol in slime. The workaround seems to >> be to revert libthr to r216640. > >> Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@ >> in case it's the latter one. > > I find it quite possible that this was an SBCL bug. > > It would be much appreciated if you could try with current HEAD from > SBCL's git repository if it makes things better. I've tried git master (as of d0d44cc) and sb-thread build passes fine, mailbox.interrupts-safety.1 test no longer hangs. Also tried on stumpwm + slime (:spawn) setup, it no longer crashes. -- FreeBSD 10.0-CURRENT r227674M amd64 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
Methinks your $TERM is set incorrectly. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
On Sat, Nov 19, 2011 at 10:32:50AM +0100, Robert Millan wrote: > 2011/11/18 Robert Millan : > > 2011/11/17 John Baldwin : > >> Hmm, I wonder if it's better to use the #ifndef approach rather than #undef > >> so that when compilers are updated to DTRT we will honor their settings? > > > > Well, the compiler is supposed to know better than sys/param.h, > > I gave this a bit more thought > > The compiler knows about the system it was intended to build for, but > sys/param.h *is* part of the system we're building for. It's > impossible for sys/param.h to have the wrong information unless it's > out of sync with the rest of the headers. > > As for the compiler, on FreeBSD it's hard for the compiler to be out > of sync, because the system (in comparison with others) is tightly > packaed and upgrade procedures are well defined. > > But if you take Debian, for example, we use the same compiler to build > 8-STABLE, 9-STABLE and 10-CURRENT kernels. The compiler has no idea > which version of FreeBSD the sources it is building come from. > > I wouldn't put compilers in general in a position where they're forced > to know the FreeBSD major version beforehand because sys/param.h will > give preference to the information coming from compiler. > > I propose this alternate patch which derives the major number from > __FreeBSD_version instead. I fully agree with an idea that compiler is not an authorative source of the knowledge of the FreeBSD version. Even more, I argue that we shall not rely on compiler for this at all. Ideally, we should be able to build FreeBSD using the stock compilers without local modifications. Thus relying on the symbols defined by compiler, and not the source is the thing to avoid and consistently remove. We must do this to be able to use third-party tooldchain for FreeBSD builds. That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ? And then make more strong wording about other systems that use the macro, e.g. remove 'may' from the kFreeBSD example. Also, please remove the smile from comment. pgpkjFIJ5nrvj.pgp Description: PGP signature
Re: 9RC2 amd64 "Can't work out which disk we are booting from"
...and booting dvd rc2 iso works. I actually installed from it to the usbdisk, just booting usb is broken. On the side note, bsdinstall is OK, missing maybe space/enter mapped action reminder, and certainly "back" button. -- View this message in context: http://freebsd.1045724.n5.nabble.com/9RC2-amd64-Can-t-work-out-which-disk-we-are-booting-from-tp5006547p5007183.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9RC2 amd64 "Can't work out which disk we are booting from"
Actually when I was trying to build amd64 image from sources from about PRE-RC1 I have exactly same error. But I have not found what it was, and switched to build i386 images only yet. 2011/11/19 Jakub Lach > Hello. > > I'm almost positive it's probably my fault, > but anyway, I have installed FreeBSD on > laptop from source (9-STABLE), on the same > machine I can't boot RC2 usb.img due to "Can't > work out which disk we are booting.." and after > installing RC2 on usbstick and trying to boot > it, same problem occurs. > (well, surprise). > > I have used default layout on usbdrive. > > Any ideas? > > ls show files structure, but boot /boot/kernel > doesn't work. > > On the side note, Verbatim STORE N GO 2.66 > 8GB gave me nothing but problems, not > recommended. (it's actually "Blaze Drive" > but it's recognised as store 'n go) > > best regards, > - Jakub Lach > > -- > View this message in context: > http://freebsd.1045724.n5.nabble.com/9RC2-amd64-Can-t-work-out-which-disk-we-are-booting-from-tp5006547p5006547.html > Sent from the freebsd-current mailing list archive at Nabble.com. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Regards, Alexander Yerenkow ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
Am 19.11.2011 um 17:29 schrieb Jason Edwards: > Dear list, > > Has anyone noticed the easy editor is quite bugged on 9.0? On console > direct access, opening the easy editor has several bugs: > > 1) the cursor starts on line 2 instead of line 1 > 2) the line numbering is printed on line 1 instead of the boundary (line 0) > 3) the keys page up and page down bring the escape menu > > Strange enough, if I SSH into the box the ee editor works normally. So > I'm wondering if this is something other people have noticed? Just > want to exclude the possibility of me doing something wrong. > > I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2, > amd64. GENERIC kernel and tested inside Virtualbox. Working fine here on 9.0-RC1. Is this a fresh install, or did you upgrade? Have you updated your ttys to set the terminal type to xterm instead of cons25? Stefan -- Stefan BethkeFon +49 151 14070811 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread
On Wed, Oct 12, 2011 at 12:00:07AM +, Nali Toja wrote:
> After r216641 sbcl built with sb-thread dies on mailbox tests. It also
> dies when I try to complete a symbol in slime. The workaround seems to
> be to revert libthr to r216640.
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154050
> http://svn.freebsd.org/changeset/base/216641
> http://www.freshports.org/lang/sbcl # or see ports/161444 for sbcl-1.0.52
> Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@
> in case it's the latter one.
[snip]
> Fatal error 'thread was already on queue.' at line 222 in file
> /usr/src/lib/libthr/thread/thr_cond.c (errno = 0)
[snip]
> (gdb) bt
> #0 0x000800c5c7ec in _umtx_op_err () at
> /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37
> #1 0x000800c5423e in _thr_umtx_timedwait_uint (mtx=0x8006d4ea8, id=0,
> clockid=0, abstime=0x0, shared=0) at /usr/src/lib/libthr/thread/thr_umtx.c:214
> #2 0x000800c5c04b in _thr_sleep (curthread=0x828d5d400, clockid=0,
> abstime=0x0) at /usr/src/lib/libthr/thread/thr_kern.c:212
> #3 0x000800c5f5dd in cond_wait_user (cvp=0x828fdf850, mp=0x828fe0970,
> abstime=0x0, cancel=1) at /usr/src/lib/libthr/thread/thr_cond.c:243
> #4 0x000800c5f856 in cond_wait_common (cond=0x8480f0008,
> mutex=0x8480f, abstime=0x0, cancel=1) at
> /usr/src/lib/libthr/thread/thr_cond.c:299
> #5 0x000800c5f8b7 in __pthread_cond_wait (cond=0x8480f0008,
> mutex=0x8480f) at /usr/src/lib/libthr/thread/thr_cond.c:313
> #6 0x0008009e9fa0 in pthread_cond_wait_exp (p0=0x8480f0008,
> p1=0x8480f) at /usr/src/lib/libc/gen/_pthread_stubs.c:217
> #7 0x00413574 in wait_for_thread_state_change (thread=0x8480f0010,
> state=16) at thread.h:53
> #8 0x004133a8 in sig_stop_for_gc_handler (signal=31,
> info=0x847eef630, context=0x847eef2c0) at interrupt.c:1265
> #9 0x0041427d in low_level_handle_now_handler (signal=31,
> info=0x847eef630, void_context=0x847eef2c0) at interrupt.c:1729
> #10 0x7023 in ?? ()
> #11 0x00414220 in low_level_unblock_me_trampoline () at
> interrupt.c:1723
> #12 0x00100154c990 in ?? ()
> #13 0x0063eaa0 in interrupt_handlers ()
> #14 0x000200411d4f in ?? ()
> #15 0x001003375721 in ?? ()
> #16 0x38b48504001a in ?? ()
> #17 0x000a81f0 in ?? ()
> #18 0x in ?? ()
> #19 0x000847eef840 in ?? ()
> #20 0x001003af2a2f in ?? ()
> #21 0x002004e9c3e1 in ?? ()
> #22 0x000800c58570 in _sigprocmask (how=Could not find the frame base
> for "_sigprocmask".
> ) at /usr/src/lib/libthr/thread/thr_sig.c:584
> Previous frame inner to this frame (corrupt stack?)
> (gdb) f 7
> #7 0x00413574 in wait_for_thread_state_change (thread=0x8480f0010,
> state=16) at thread.h:53
> 53 pthread_cond_wait(thread->state_cond, thread->state_lock);
> (gdb) l
> 48 static inline void
> 49 wait_for_thread_state_change(struct thread *thread, lispobj state)
> 50 {
> 51 pthread_mutex_lock(thread->state_lock);
> 52 while (thread->state == state)
> 53 pthread_cond_wait(thread->state_cond, thread->state_lock);
> 54 pthread_mutex_unlock(thread->state_lock);
> 55 }
> 56
> 57 extern pthread_key_t lisp_thread;
The cause of the trouble appears to be that pthread_cond_wait() is
interrupted by a signal handler and the signal handler calls
pthread_cond_wait() again (no matter whether it is on the same or a
different condition variable). POSIX forbids this because (like most of
the pthread functions) pthread_cond_wait() is not async-signal-safe.
While the pre-r216641 code is not async-signal-safe either, it would
usually work fine. With the r216641 code, the second call to
pthread_cond_wait() aborts immediately with the 'thread was already on
queue' message.
The immediate issue could be fixed in libthr fairly easily by enabling
its code to postpone signal handlers also during pthread_cond_wait() (a
signal will still interrupt the wait). However, this does not fix issues
due to signal handlers interrupting other pthread functions which may
still cause erratic undefined behaviour. Therefore, it may not be
desirable to do this.
An alternative is to use pthread_suspend_np(). This function will wait
for the thread to stop before returning, although it may stop almost
anywhere. I have not tried this but calling it on a thread in
pthread_cond_wait() should be safe.
Ideally, it would not be necessary to stop all other threads while
collecting garbage, but this may be hard to fix.
--
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ee (easy editor) bugged on 9.0?
Dear list, Has anyone noticed the easy editor is quite bugged on 9.0? On console direct access, opening the easy editor has several bugs: 1) the cursor starts on line 2 instead of line 1 2) the line numbering is printed on line 1 instead of the boundary (line 0) 3) the keys page up and page down bring the escape menu Strange enough, if I SSH into the box the ee editor works normally. So I'm wondering if this is something other people have noticed? Just want to exclude the possibility of me doing something wrong. I've noticed this behavior on 9-CURRENT, 9.0-RC1 as well as 9.0-RC2, amd64. GENERIC kernel and tested inside Virtualbox. Regards, Jason ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [Sbcl-bugs] crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread
On 12 October 2011 03:00, Nali Toja wrote: > After r216641 sbcl built with sb-thread dies on mailbox tests. It also > dies when I try to complete a symbol in slime. The workaround seems to > be to revert libthr to r216640. > Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@ > in case it's the latter one. I find it quite possible that this was an SBCL bug. It would be much appreciated if you could try with current HEAD from SBCL's git repository if it makes things better. Cheers, -- Nikodemus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-RC2 Available...
> On 18/11/2011 10:53, Thomas Mueller wrote: > > *default release=cvs tag=RELENG_9 > > Am I screwed, am I OK, or do I simply have to rerun csup with RELENG_9_0 > > instead of RELENG_9 ? > Not screwed, but you'll be running 9.0-PRERELEASE rather than 9.0-RC2. > If you want to switch to the 9.0-RELEASE branch, change the tag to > RELENG_9_0 and cvsup again. Then redo the whole buildworld dance. > Cheers, > Matthew > -- > Dr Matthew J Seaman MA, D.Phil. Good to know I'm not screwed, that I can recover simply by rerunning csup, this time with RELENG_9_0 instead of RELENG_9. But I hadn't got to making buildworld yet on this update. Possibly there may be no serious difference between 9.0-PRERELEASE and 9.0-RC2 at this stage. As for the difference between STABLE and RELEASE, I believe STABLE is a sort of POSTRELEASE, like the post-release update to NetBSD 5.1 that permitted access to Linux ext2fs partition that didn't work previously with NetBSD; inode was 256 bytes. I think FreeBSD 9-STABLE (RELENG_9) would be development work toward FreeBSD 9.1, after FreeBSD 9.0 is released, but stabler than current/head. I looked in /usr/src/sys/conf/newvars.sh and indeed found that I had 9.0-PRERELEASE rather than RC2. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
9RC2 amd64 "Can't work out which disk we are booting from"
Hello. I'm almost positive it's probably my fault, but anyway, I have installed FreeBSD on laptop from source (9-STABLE), on the same machine I can't boot RC2 usb.img due to "Can't work out which disk we are booting.." and after installing RC2 on usbstick and trying to boot it, same problem occurs. (well, surprise). I have used default layout on usbdrive. Any ideas? ls show files structure, but boot /boot/kernel doesn't work. On the side note, Verbatim STORE N GO 2.66 8GB gave me nothing but problems, not recommended. (it's actually "Blaze Drive" but it's recognised as store 'n go) best regards, - Jakub Lach -- View this message in context: http://freebsd.1045724.n5.nabble.com/9RC2-amd64-Can-t-work-out-which-disk-we-are-booting-from-tp5006547p5006547.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
2011/11/18 Robert Millan : > 2011/11/17 John Baldwin : >> Hmm, I wonder if it's better to use the #ifndef approach rather than #undef >> so that when compilers are updated to DTRT we will honor their settings? > > Well, the compiler is supposed to know better than sys/param.h, I gave this a bit more thought The compiler knows about the system it was intended to build for, but sys/param.h *is* part of the system we're building for. It's impossible for sys/param.h to have the wrong information unless it's out of sync with the rest of the headers. As for the compiler, on FreeBSD it's hard for the compiler to be out of sync, because the system (in comparison with others) is tightly packaed and upgrade procedures are well defined. But if you take Debian, for example, we use the same compiler to build 8-STABLE, 9-STABLE and 10-CURRENT kernels. The compiler has no idea which version of FreeBSD the sources it is building come from. I wouldn't put compilers in general in a position where they're forced to know the FreeBSD major version beforehand because sys/param.h will give preference to the information coming from compiler. I propose this alternate patch which derives the major number from __FreeBSD_version instead. Index: sys/sys/param.h === --- sys/sys/param.h (revision 227580) +++ sys/sys/param.h (working copy) @@ -60,6 +60,23 @@ #undef __FreeBSD_version #define __FreeBSD_version 101 /* Master, propagated to newvers */ +/* + * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, + * which by definition is always true on FreeBSD :-). This macro may also + * be defined on other systems that use the kernel of FreeBSD, such as + * GNU/kFreeBSD. + * + * It is tempting to use this macro in userland code when we want to enable + * kernel-specific routines, and in fact it's fine to do this in code that + * is part of FreeBSD itself. However, be aware that as presence of this + * macro is still not widespread (e.g. older FreeBSD versions, 3rd party + * compilers, etc), it is STRONGLY DISCOURAGED to check for this macro in + * external applications without also checking for __FreeBSD__ as an + * alternative. + */ +#undef __FreeBSD_kernel__ +#define __FreeBSD_kernel__ (__FreeBSD_version / 10) + #ifdef _KERNEL #define P_OSREL_SIGWAIT 70 #define P_OSREL_SIGSEGV 74 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
