Re: [RFC] support -b baudrate when starting gdb
On Jan 16, 2013, at 7:35 AM, Warner Losh i...@bsdimp.com wrote:
How does 'set remotebaud' not do what you want?
Warner
On Jan 15, 2013, at 10:15 PM, Adrian Chadd wrote:
Hi,
There doesn't seem to be a blessed way to set the baudrate from inside
gdb/kgdb. It seems to be set from '-b' on the command line.
However kgdb doesn't have this support.
This patch adds -b support so kgdb so I can override the default speed
(9600 it seems) to speak kgdb over serial to a 115200 console MIPS
device.
The MIPS stuff has other issues; I'll talk about those later.
Thanks,
Adrian
Index: gnu/usr.bin/gdb/kgdb/main.c
===
--- gnu/usr.bin/gdb/kgdb/main.c (revision 245281)
+++ gnu/usr.bin/gdb/kgdb/main.c (working copy)
@@ -333,11 +333,24 @@
args.argv = malloc(sizeof(char *));
args.argv[0] = argv[0];
- while ((ch = getopt(argc, argv, ac:d:fn:qr:vw)) != -1) {
+ while ((ch = getopt(argc, argv, ab:c:d:fn:qr:vw)) != -1) {
switch (ch) {
case 'a':
annotation_level++;
break;
+ case 'b':
+ {
+ int i;
+ char *p;
+
+ i = strtol (optarg, p, 0);
+ if (i == 0 p == optarg)
+ warnx(warning: could not set baud
rate to `%s'.\n,
+ optarg);
+ else
+ baud_rate = i;
+ }
+ break;
case 'c': /* use given core file. */
if (vmcore != NULL) {
warnx(option %c: can only be specified once,
It's more of a convenience factor and easier to script command line arguments
IMO.
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: off topic but no idea where to ask
On Jan 15, 2013, at 10:18 AM, Wojciech Puchar wrote: does anyone know a PXE image (just like /boot/pxeboot) that can be placed on tftp server and the only thing it will do would be loading first sector from first local disk at 0x07c00 and booting as with normal hard drive. what i need is to be able to decide from server side if given computer boots from NFS or hard disk. Sounds like a job for PXE-enabled grub, but you probably can hack loader (pxeboot to be exact) to do the same thing. It would be nice to have a feature like this in mainline FreeBSD… Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is it possible to block pending queued RealTime signals (AIO originating)?
On Jan 8, 2013, at 9:20 AM, Adrian Chadd adr...@freebsd.org wrote: On 8 January 2013 08:15, Richard Sharpe rsha...@richardsharpe.com wrote: On Tue, 2013-01-08 at 07:36 -0800, Adrian Chadd wrote: .. or you could abstract it out a bit and use freebsd's aio_waitcomplete() or kqueue aio notification. It'll then behave much saner. Yes, going forward that is what I want to do ... this would work nicely with a kqueue back-end for Samba's tevent subsystem, and if someone has not already written such a back end, I will have to do so, I guess. Embrace FreeBSD's nice asynchronous APIs for doing things! You know you want to! (Then, convert parts of samba over to use grand central dispatch... :-) Seriously though - I was doing network/disk IO using real time signals what, 10 + years ago on Linux and it plain sucked. AIO + kqueue + waitcomplete is just brilliant. kqueue for signal delivery is also just brilliant. Just saying. Or just use libevent to abstract away kqueues/inotify/etc? Samba isn't just for freebsd... Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Cross Compiling of ports Makefiles.
On Mon, Dec 31, 2012 at 6:33 AM, Michael Vale mas...@internode.on.net wrote:
-Original Message- From: Simon J. Gerraty
Sent: Friday, December 28, 2012 5:00 AM
To: Michael Vale
Cc: freebsd-hackers@freebsd.org ; freebsd-a...@freebsd.org ;
freebsd-po...@freebsd.org
Subject: Re: Cross Compiling of ports Makefiles.
Doing the same thing could also prevent the need for a DESTDIR JAIL
install at all and just use the real build machine’s build env, rather
than a jail. Regardless. We still have to install these targets and
their DESTDIR is skewed. There is a few options,
I think I know what you mean, but not clear on the their DESTDIR is
skewed bit.
You were probably thinking of PREFIX, not DESTDIR. DESTDIR in
ports-land should be an install directory wherein if I do...
./configure --prefix=/usr/local
make all
make install DESTDIR=/chroot/
It would install all (well, ok most if it needs to touch more of the
base system) of the package files into /chroot/usr/local and pathing
would be setup appropriately that way.
I'm not sure what I meant here either. Thank-you for taking the time to
read the entire e-mail! :)
One is to have a MAKEOBJDIRPREFIX like option, and redefine every
target’s DESTDIR ${makeobjDESTDIR} before running do-install. Now i’ve
yet to complete this stage, but I believe this is the way to do it.
Would it be sufficient to have an INSTALL_PREFIX and/or INSTALL_DESTDIR
so that DESTDIR can be different during install ?
[I was recently experimenting with something similar...]
So how would that work?
pre-install:
INSTALL_DESTDIR=/usr/obj/crossoutroot/
DESTDIR=${INSTALL_DESTDIR}
do-install:
? I will try something like that.
Thank-you for taking the time to reply Simon,
I've thought about this item quite a bit and while I might not have
hashed out all of the internal details, I think that it should go
something like this:
0. Run standard build/install targets which will go and create
necessary binaries into a predefined world dir.
Once the installation is complete (installworld / distribution)...
1. Mount the necessary mountpoints.
2. Install the host-compiled tools into a predefined set of
directories. Example:
/chroot/h/bin
/chroot/h/sbin
/chroot/h/usr/bin
/chroot/h/usr/libexec
/chroot/h/usr/sbin
3. Do a nullfs overlay of the host-compiled tools on top of the
target system's equivalent directories in order to provide the needed
bits for executing the build.
4. Verify sanity for the install base (just in case the new binaries
don't run on the host system due to KPI differences) with a basic
check like we use for make in `upgrade_checks`.
5. Mock up the build environment to look like the target system, like
what's described .
6. Jump into the world dir.
7. Start building/installing packages.
Notes:
I'm suggesting steps 2. and 3. because while fixing hardcoding in
ports packages is a noble effort, there's just way too much work to be
done in order to accomplish the job (we have other problems to contend
with around the ports tree) and it's an ongoing battle trying to get
everyone to use sane build methodologies (I'm making an assumption
based on several projects I've used, but many devs aren't capable
build system engineers because it takes a bit of mental skewing, so
hardcoding abounds in a number of places). Doing this will allow us to
have a working prototype quicker, so in the event that others wish to
make the process more streamlined in the future, they could do so.
Whether or not this handled in the FreeBSD build system or outside it
is an implementation detail, but for the sake of modularity (and to
keep KISS principle with the FreeBSD build system, which I would argue
is complicated enough) I would say make them separate processes.
Besides, we already have canned methods for doing this in NanoBSD,
PicoBSD, etc already -- and they really could deserve some
consolidation (speaking of which, have you looked at using these in
zrouter?).
You might want to look at FreeNAS 8.x's build architecture and use
that as a starting point for how to do things. imp@ designed the
initial system, I (gcooper@) modified it heavily, and
jhixson@/jpaetzel@ modified it more after I left iXsystems in order to
work with their plugin architecture. I can send you a copy of the
system I was starting to architect (Avatar) if you wish.
Overall, I like the direction you're going in and I'm glad someone is
picking this up. I greatly appreciate it because it's been on my
laundry list of items that need to get done for some time :).
HTH,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cvs deprecated
On Thu, Dec 27, 2012 at 1:18 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: but i can't find moron guide for using svn to update tree. I never used cvs or svn myself just want to 1) get latest FreeBSD 9-* sources 2) get latest HEAD sources. 1. Checkout the sources: cd /usr/src # Change to something else if you don't want to checkout to /usr/src. svn co http://svn.freebsd.org/base/stable/9 . # stable/9 svn co http://svn.freebsd.org/base/head . # CURRENT 2. Updating: cd /usr/src # Same caveat as above. svn up See also: http://www.freebsd.org/doc/handbook/svn.html . ... HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cvs deprecated
On Thu, Dec 27, 2012 at 2:30 AM, Chris Rees utis...@gmail.com wrote: On 27 Dec 2012 09:47, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Dec 27, 2012 at 1:18 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: but i can't find moron guide for using svn to update tree. I never used cvs or svn myself just want to 1) get latest FreeBSD 9-* sources 2) get latest HEAD sources. 1. Checkout the sources: cd /usr/src # Change to something else if you don't want to checkout to /usr/src. svn co http://svn.freebsd.org/base/stable/9 . # stable/9 svn co http://svn.freebsd.org/base/head . # CURRENT I recall a cluster administrator advising use of svn protocol rather than http. Something to do with overheads. Yes, you're right. http opens a connection per-file, which is horrendous with server load and is very slow as HTTP isn't optimized for this purpose (and the current defacto HTTP library used with svn isn't the most performant thing in the world). Unfortunately some groups filter svn:// traffic though (like my employer), so I'm stuck with http:// URIs for now (hence, the force of habit). Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cvs deprecated
On Thu, Dec 27, 2012 at 6:50 AM, Warren Block wbl...@wonkity.com wrote: ... I see a lot of people switching to the target directory first rather than just including it as an argument for svn. Is there an advantage there that I'm missing? I've always just used svn co http://svn.freebsd.org/base/stable/9 /usr/src and svn up /usr/src No difference really, other than the cumulative amount of typed characters is less in the former form compared to the latter form. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cvs deprecated
On Thu, Dec 27, 2012 at 7:28 AM, RW rwmailli...@googlemail.com wrote: On Thu, 27 Dec 2012 02:33:00 -0800 Garrett Cooper wrote: On Thu, Dec 27, 2012 at 2:30 AM, Chris Rees utis...@gmail.com wrote: I recall a cluster administrator advising use of svn protocol rather than http. Something to do with overheads. Yes, you're right. http opens a connection per-file, which is horrendous with server load and is very slow as HTTP isn't optimized for this purpose Presumably that's a limitation of the library or subversion because it's not true of HTTP per se. Portsnap, for example, uses persistent connections with pipelining. An example of what I mean [1]: === A checkout/update over svn:// is approx 4-12 times faster than over http(s):// . The factor depends on number of files/folders and file size . Apache is much slower on many small files because each file is a full http-request-response cycle. In Tortoise you can easily see the speed dropping: Checkout a large java projects If you transfer a huge .jar, transfer is going up, on getting source java files and creating package structure, it will drop. Also important is that svn checkout is slower on client than svn export and also eclipse(java) is much slower than tortoise/CMD. share|improve this answer === Qualitatively we (my group) have seen a huge performance increase in our svnsyncs from freebsd.org using svn:// instead of http:// . We haven't measured how much the difference is quantatively though because a qualitative answer was sufficient for helping reinforce a business case for unfiltering that port with corporate. HTH, -Garrett 1. http://stackoverflow.com/questions/372569/subversion-protocol-performance ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cvs deprecated
On Dec 27, 2012, at 8:37 AM, Sergey Matveychuk s...@freebsd.org wrote: 27.12.2012 20:29, Sam Fourman Jr. wrote: On Thu, Dec 27, 2012 at 4:18 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: but i can't find moron guide for using svn to update tree. I cant seem to find a way to handle conflicts, ive tried to do svn revert on every directory, but there is always more... maybe svn just isnt a good way to keep your ports tree current svn up Updating '.': Skipped 'databases' -- Node remains in conflict Skipped 'irc' -- Node remains in conflict Skipped 'lang' -- Node remains in conflict Skipped 'security/cyrus-sasl2' -- Node remains in conflict Skipped 'x11/keybinder' -- Node remains in conflict Skipped 'net-mgmt' -- Node remains in conflict At revision 309546. Summary of conflicts: Skipped paths: 6 svn revert -R /usr/ports - works for me. If you're checking out to a directory that already exists, svn resolved is the way to handle that. There might be (- probably is) a way to check out the metadata by itself, but I can't verify how right now. Hth, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files
On Sun, Dec 23, 2012 at 8:26 AM, Ed Maste ema...@freebsd.org wrote: On 22 December 2012 23:13, Alfred Perlstein bri...@mu.org wrote: I have a patch for this. I am building world to see what happens, if you want to try it, or comment on it, please let me know. Changes are: base DEBUGDIR on LIBDIR for ports create intermediate directories for debug objs. Note that just moving ports debug data to /usr/local/lib/debug/... won't work since GDB won't search there. We could teach it to search a list of paths and include /usr/local/lib/debug and /usr/lib/debug, or perhaps a symlink under /usr/local/lib. We could also use a .debug subdirectory for ports and other users of bsd.lib.mk - so for example /usr/local/lib/libfoo.so would have debug info in /usr/local/lib/.debug/libfoo.so.debug. Crazy idea: why not just provide the user with an example .gdbinit that does these things? For Isilon it makes more sense to tack on additional paths (which we already do in our internal directions), and others potentially are doing similar *shrugs*, so as long as the example makes sense, I'd stick with it. I would probably setup things in such a way that the old default is kept though because I'm sure that there's someone out there that's using it (even it it's not *the best* default per how we prefix things in ports). Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: uart: add resume method
On Sun, Dec 23, 2012 at 5:36 AM, Andriy Gapon a...@freebsd.org wrote: Guys, do you think that the following change is useful/needed? I needed it with UART emulated in qemu, but I have no experience with real hardware. I assume that you suspended the emulator and the UART didn't come back to life? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files
On Sun, Dec 23, 2012 at 5:24 PM, Eitan Adler li...@eitanadler.com wrote: On 23 December 2012 16:47, Garrett Cooper yaneg...@gmail.com wrote: I would probably setup things in such a way that the old default is kept though because I'm sure that there's someone out there that's using it (even it it's not *the best* default per how we prefix things in ports). If the old defaults aren't the best defaults - I'd change them. If someone depends on the old defaults they should be explicitly set. POLA should not impede progress. Good point. Should this be documented in UPDATING? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files
On Sat, Dec 22, 2012 at 8:13 PM, Alfred Perlstein bri...@mu.org wrote: On 12/22/12 6:14 PM, Jan Beich wrote: Ed Maste ema...@freebsd.org writes: When this knob is set standalone debug files for shared objects are built and installed in /usr/lib/debug/so pathname.debug. GDB searches this path for debug data. [...] What about ports? They are not allowed to install outside of PREFIX. $ cd multimedia/cuse4bsd-kmod $ make install PREFIX=/tmp/aaa PKG_DBDIR=/tmp/pkg WITH_DEBUG= [...] install -C -o root -g wheel -m 444 libcuse4bsd.a /tmp/aaa/lib install -s -o root -g wheel -m 444 libcuse4bsd.so.1 /tmp/aaa/lib install -o root -g wheel -m 444libcuse4bsd.so.1.debug /usr/lib/debug/tmp/aaa/lib install: /usr/lib/debug/tmp/aaa/lib: No such file or directory *** [_libinstall] Error code 71 I have a patch for this. I am building world to see what happens, if you want to try it, or comment on it, please let me know. Changes are: base DEBUGDIR on LIBDIR for ports create intermediate directories for debug objs. One thing about this (and the original patch) that may or may not make sense is that DEBUGDIR should be undefined and passed in via CFLAGS in the Makefile (reason being is that it would reduce duplication IMO and it's less duplicated magic juju hanging around some gdb header files). Another thing that might be a good idea is that the changes in bsd.lib.mk diverge from standard expectations for the file extension (.symbols - .debug), so at the very least this should be documented. Finally, what about debug symbols for programs (bsd.prog.mk)? I assume that's coming soon, but I figured I should ask :). Thanks! -Garrett PS Awesome solution for the ports issue :). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files
On Sat, Dec 22, 2012 at 9:42 PM, Alfred Perlstein bri...@mu.org wrote: ... Buildworld breaks with this for me using my patch, no idea what this all means yet. Will look into it: exer.c -o nslexer.So ctfconvert -L VERSION crypt_xdr.o ctfconvert -L VERSION crypt_clnt.o ctfconvert -L VERSION nsparser.So ctfconvert -L VERSION nsparser.o ctfconvert -L VERSION crypt_clnt.So ctfconvert -L VERSION crypt_xdr.So ctfconvert -L VERSION yp_xdr.o ctfconvert -L VERSION subr_acl_nfs4.So ctfconvert -L VERSION nslexer.o ctfconvert -L VERSION yp_xdr.So ctfconvert -L VERSION subr_acl_nfs4.o building static c library ctfconvert -L VERSION nslexer.So building shared library libc.so.7 building special pic c library BFD: dlfcn.o: invalid SHT_GROUP entry BFD: dlfcn.o: invalid SHT_GROUP entry BFD: dlfcn.o: invalid SHT_GROUP entry BFD: dlfcn.o: invalid SHT_GROUP entry BFD: dlfcn.o: no group info for section .text._rtld_error BFD: dlfcn.o: no group info for section .text.dladdr BFD: dlfcn.o: no group info for section .text.dlclose BFD: dlfcn.o: no group info for section .text.dlerror BFD: dlfcn.o: no group info for section .text.dllockinit BFD: dlfcn.o: no group info for section .text.dlopen BFD: dlfcn.o: no group info for section .text.dlsym BFD: dlfcn.o: no group info for section .text.dlvsym BFD: dlfcn.o: no group info for section .text.dlinfo BFD: dlfcn.o: no group info for section .text._rtld_thread_init BFD: dlfcn.o: no group info for section .text._rtld_atfork_post BFD: dlfcn.o: no group info for section .text._rtld_get_stack_prot nm: dlfcn.o: File format not recognized BFD: elf_utils.o: invalid SHT_GROUP entry BFD: elf_utils.o: no group info for section .text.__pthread_map_stacks_exec BFD: elf_utils.o: unknown [0] section `' in group [__pthread_map_stacks_exec] nm: elf_utils.o: File format not recognized ranlib libc_pic.a BFD: __vdso_gettc.o: invalid SHT_GROUP entry BFD: __vdso_gettc.o: no group info for section .text.__vdso_gettc BFD: __vdso_gettc.o: unknown [0] section `' in group [__vdso_gettc] nm: __vdso_gettc.o: File format not recognized BFD: __vdso_gettimeofday.o: invalid SHT_GROUP entry BFD: __vdso_gettimeofday.o: invalid SHT_GROUP entry BFD: __vdso_gettimeofday.o: no group info for section .text.__vdso_gettimeofday BFD: __vdso_gettimeofday.o: no group info for section .text.__vdso_clock_gettime BFD: __vdso_gettimeofday.o: unknown [0] section `' in group [__vdso_gettimeofday] BFD: __vdso_gettimeofday.o: unknown [0] section `' in group [__vdso_clock_gettime] nm: __vdso_gettimeofday.o: File format not recognized BFD: dlfcn.So: invalid SHT_GROUP entry BFD: dlfcn.So: invalid SHT_GROUP entry BFD: dlfcn.So: invalid SHT_GROUP entry BFD: dlfcn.So: invalid SHT_GROUP entry BFD: dlfcn.So: no group info for section .text._rtld_error BFD: dlfcn.So: no group info for section .text.dladdr BFD: dlfcn.So: no group info for section .text.dlclose BFD: dlfcn.So: no group info for section .text.dlerror BFD: dlfcn.So: no group info for section .text.dllockinit BFD: dlfcn.So: no group info for section .text.dlopen BFD: dlfcn.So: no group info for section .text.dlsym BFD: dlfcn.So: no group info for section .text.dlvsym BFD: dlfcn.So: no group info for section .text.dlinfo BFD: dlfcn.So: no group info for section .text._rtld_thread_init BFD: dlfcn.So: no group info for section .text._rtld_atfork_post BFD: dlfcn.So: no group info for section .text._rtld_get_stack_prot BFD: dlfcn.So: unknown [2] section `.symtab' in group [dl_iterate_phdr] BFD: dlfcn.So: unknown [0] section `' in group [_rtld_atfork_pre] BFD: dlfcn.So: unknown [0] section `' in group [_rtld_atfork_post] BFD: dlfcn.So: unknown [0] section `' in group [_rtld_addr_phdr] BFD: dlfcn.So: unknown [0] section `' in group [_rtld_get_stack_prot] nm: dlfcn.So: File format not recognized BFD: elf_utils.So: invalid SHT_GROUP entry BFD: elf_utils.So: no group info for section .text.__pthread_map_stacks_exec BFD: elf_utils.So: unknown [0] section `' in group [__pthread_map_stacks_exec] nm: elf_utils.So: File format not recognized BFD: __vdso_gettc.So: invalid SHT_GROUP entry BFD: __vdso_gettc.So: no group info for section .text.__vdso_gettc BFD: __vdso_gettc.So: unknown [0] section `' in group [__vdso_gettc] nm: __vdso_gettc.So: File format not recognized BFD: __vdso_gettimeofday.So: invalid SHT_GROUP entry BFD: __vdso_gettimeofday.So: invalid SHT_GROUP entry BFD: __vdso_gettimeofday.So: no group info for section .text.__vdso_gettimeofday BFD: __vdso_gettimeofday.So: no group info for section .text.__vdso_clock_gettime BFD: __vdso_gettimeofday.So: unknown [0] section `' in group [__vdso_gettimeofday] BFD: __vdso_gettimeofday.So: unknown [0] section `' in group [__vdso_clock_gettime] nm: __vdso_gettimeofday.So: File format not recognized ranlib libc.a /usr/obj/usr/home/alfred/freebsd/tmp/usr/bin/ld: __vdso_gettimeofday.So: invalid SHT_GROUP entry
Re: [PATCH] Shared library debug .symbols files
On Thu, Dec 13, 2012 at 2:07 PM, Eric van Gyzen e...@vangyzen.net wrote: ... dot-SHLIB_NAME? I'm not aware of this magic. Looks like a typo: $ make -V.SHLIB_NAME $ make -VSHLIB_NAME libc.so.7 Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: loader and ficl/Forth help
On Fri, Dec 7, 2012 at 1:07 AM, Devin Teske devin.te...@fisglobal.com wrote: ... I've made some improvements to the supplied patch. Said improvements should address the previous issues that were preventing this from going in. Can someone test the newly-attached patch.txt and get back to me? The patch seems to be missing a few checks (boot_multicons, boot -D, etc). I really wish this stuff was properly consolidated/cleaned up -- loader.conf's console stuff is a hodgepodge mess of duplicated/obfuscated user knobs. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: loader and ficl/Forth help
On Fri, Dec 7, 2012 at 12:07 PM, Devin Teske devin.te...@fisglobal.com wrote:
...
I'll look into boot_multicons.
However, w/respect to boot -D, I believe that would be after the menu, so
is past the point at which we need the functionality (in drawing frames from
frames.4th).
Also, you replied to an earlier e-mail in the thread, do note that there's an
updated patch that centralizes the logic to boot_serial? function which
returns boolean based on multiple conditions (currently takes $console and
$boot_serial into consideration -- should be trivial to add a check for
boot_multicons).
You're correct; boot -D is for after boot and this only affects loader(8):
-Dboot with the dual console configuration. In the
single configuration, the console will be either
the internal display or the serial port, depending
on the state of the -h option below. In the dual
console configuration, both the internal display
and the serial port will become the console at the
same time, regardless of the state of the -h
option.
Rereading loader(8)'s entry on multicons, it might be a non-issue as
well, given that it's only saying kernel:
boot_multicons
Enables multiple console support in the kernel early on boot.
In a running system, console configuration can be manipulated
by the conscontrol(8) utility.
A grep of sys/boot suggests it's an alias for -D:
$ grep -r multicons .
./userboot/userboot/bootinfo.c:{boot_multicons, RB_MULTIPLE},
./sparc64/loader/metadata.c:{boot_multicons, RB_MULTIPLE},
./forth/loader.conf:#boot_multicons= # -D: Use multiple consoles
^^^
./powerpc/ofw/metadata.c:{boot_multicons, RB_MULTIPLE},
./powerpc/ps3/metadata.c:{boot_multicons, RB_MULTIPLE},
./i386/libi386/comconsole.c:getenv(boot_multicons) != NULL) {
./i386/libi386/bootinfo.c:{boot_multicons,RB_MULTIPLE},
./i386/efi/bootinfo.c: { boot_multicons, RB_MULTIPLE},
./pc98/libpc98/comconsole.c:getenv(boot_multicons) != NULL) {
./common/loader.8:.It Va boot_multicons
./common/help.common:# Tset Sboot_multicons DUse multiple consoles
./common/help.common: set boot_multicons
./ia64/common/bootinfo.c: { boot_multicons, RB_MULTIPLE},
./uboot/common/metadata.c: {boot_multicons, RB_MULTIPLE},
However, sys/boot/i386/libi386/comconsole.c is doing some matching
based on the environment variable, so I'd need to look into the call
flow further to better understand what's being achieved.
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel module parallel build?
On Wed, Dec 5, 2012 at 8:42 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday, December 04, 2012 2:41:32 pm Ryan Stone wrote:
On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin j...@freebsd.org wrote:
Hmm, I certainly see the module directories being built in parallel. Some
of
the make jobs may not be as obvious since links are silent (no output
unless
there is an error).
This is definitely not the behaviour that I see trying to build any version
of FreeBSD. I see the same behaviour as Andre: the depend and all targets
both iterate through the module directories sequentially. It never builds
two module subdirectories concurrently.
Hmm, I think I was confused by seeing kernel builds intermingle with the
associated modules. sys/modules/Makefile uses bsd.subdir.mk. I think I see
similar things in world builds where I will see parallel builds of bin vs sbin
vs usr.bin vs usr.sbin, but within each of those directories the builds go
sequentially. I think you would need to change bsd.subdir.mk if you want to
fix this.
Correct:
45 @${_+_}for entry in ${SUBDIR}; do \
^^^ This is where things get serialized
46 if test -d ${.CURDIR}/$${entry}.${MACHINE_ARCH}; then \
Same thing applies for buildkernel building modules because it
just wraps around bsd.subdir.mk in sys/modules/Makefile . Enhancing it
to be parallel would introduce potential races. Some of the work sjg's
doing with meta make will make this unnecessary from a buildworld
perspective, but I'm not sure about buildkernel.
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel module parallel build?
On Wed, Dec 5, 2012 at 3:51 PM, Damien Fleuriot m...@my.gd wrote: ... All trolling aside, I believe an awesome fix to be setting module override in /etc/make.conf to only build the 4-5 specific modules one needs. To be honest I think this configuration tweak should be advertised a bit more as it definitely speeds up kernel builds. I would be happy to check if this is advertised in the handbook in the rebuilding kernel section and enhance its visibility if required. I can provide en_US and fr_FR. +1. Please write it up if you can; it's much quicker/better than the kitchen sink approach if you know what you're doing and don't have to build for a large set of platforms. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Missing quote in comment in 8.3 9.0 9.1RC2 etc/sendmail/freebsd.mc
On Tue, Dec 4, 2012 at 7:03 PM, Eitan Adler li...@eitanadler.com wrote: On 4 December 2012 21:23, Julian H. Stacey j...@berklix.com wrote: Hi, Reference: From: Eitan Adler li...@eitanadler.com Date: Tue, 4 Dec 2012 20:58:20 -0500 Message-id: caf6rxgk5wtmzubta_8oepez8n23+8wyf85deqs-i+igtkfj...@mail.gmail.com Eitan Adler wrote: On 4 December 2012 20:21, Julian H. Stacey j...@berklix.com wrote: At Wed Dec 5 02:16:29 CET 2012 the web ref fails: http://www.freebsd.org/cgi/query-pr.cgi?pr=174108 There is no bug in the bin category beyond 174103 This is a known issue. I'm not sure what is causing it. Your bug made it (check the freebsd-bugs mailing list) but the web interface can't find it. -- Eitan Adler Thanks Eitan, OK I see http://lists.freebsd.org/pipermail/freebsd-bugs/2012-December/051052.html Garrett C mentioned it was slow wait a bit. Normally it takes about 15 minutes for it to sync and cron to catch up.Something else is going on here. Clusteradm, can you comment? It took almost an hour on Sunday, FYI. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: old style kernel configuration
On Wed, Nov 21, 2012 at 5:58 PM, Eitan Adler li...@eitanadler.com wrote: I've been working on removing obsolete information various documents. While going through older articles I noticed a few references to the old style kernel configuration involving running config(1) manually. Is there any value in keeping this documented as an alternative to make buildkernel or should it be treated as an implementation detail? For new/non-advanced users, this shouldn't necessarily be exposed except as an implementation detail and a historical artifact; more directions, not less serve to confuse the masses - see git as a perfect example of this with all of its workflows. I think the question that should be asked first is: who's your target audience (remember, hackers are generally the more and not less advanced target audience)? Once this question can be answered, I think it would become apparent either to you and other reviewers what the text should say. Thanks, Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Give users a hint when their locate database is too small.
On Nov 13, 2012, at 8:05 AM, Eitan Adler li...@eitanadler.com wrote: On 13 November 2012 10:58, Eitan Adler li...@eitanadler.com wrote: Okay... sorry for the spam. I remember there was a reason I used /etc/periodic/weekly/310.locate instead of /usr/libexec/locate.updatedb. The latter must not be run as root, and the former takes care of this work. Since the default is to enable weekly updates I am inclined to use the 310.locate script instead. Ok. The only thing about hardcoding an RC script name into a binary is that I felt it was more likely to change whereas locate.updatedb is more constant.. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: pgbench performance is lagging compared to Linux and DragonflyBSD?
On Nov 6, 2012, at 8:55 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Tuning operating system for single benchmark is an example of that childish behaviour. LOL. That's what we did several years ago : http://people.freebsd.org/~kris/scaling/dfly.html i've seen that page some time ago but i don't really care of it. i just wasn't interested. Still - DOING such benchmark is good, as it can show general problems in used algorithms. But working on software to make it better in some kind of synthetic benchmark is common in commercial software world. (We have more performance per buck than company X) Synthetic benchmarks as you put it shouldn't be the ultimate basis for a decision, but instead allow users to gauge whether or not a certain software or hardware configuration is suitable for their given workload. No more, no less. The fact that they're being used in this manner is a bit like a salesman selling snake oil as the results aren't necessarily the result of a best configuration for all competing platforms, but instead an unknown configuration in this case. A similar statement about the importance of micro benchmarks can be made... Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: pgbench performance is lagging compared to Linux and DragonflyBSD?
On Nov 6, 2012, at 1:26 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: defaults) is sysctl/tunable variables set in the *BSD OSes (on DFly, FreeBSD, and NetBSD). Unfortunately (based on my experience) FreeBSD could be a lot better when it comes to defaults, and more tuning is required to actually FreeBSD defaults are actually good for COMMON usage. and can be tuned. default MAXBSIZE is one exception. Common usage is vague. While FreeBSD might do ok for some applications (dev box, simple workstation/laptop, etc), there are other areas that require additional tuning to get better perf that arguably shouldn't as much (or there should be templates for doing so): 10GbE and mbuf and network tuning; file server and file descriptor, network tuning, etc; low latency desktop and scheduler tweaking; etc. Not to say that freebsd is entirely at fault, but because it's more of a commodity OS that Linux, more tweaking is required... Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: pgbench performance is lagging compared to Linux and DragonflyBSD?
On Mon, Nov 5, 2012 at 10:52 AM, Yuri y...@rawbw.com wrote: There is the post by DragonflyBSD folks that claims that Linux and DragonflyBSD are quite ahead of FreeBSD on pgbench test on 12 Core 2x Xeon X5650 with 24 threads. Here are their results with graphs: http://lists.dragonflybsd.org/** pipermail/users/attachments/**20121010/7996ff88/attachment-**0002.pdfhttp://lists.dragonflybsd.org/pipermail/users/attachments/20121010/7996ff88/attachment-0002.pdf And here is their original post: http://lists.dragonflybsd.org/** pipermail/users/2012-October/**017536.htmlhttp://lists.dragonflybsd.org/pipermail/users/2012-October/017536.html I am not sure if this is the problem of some sysctl or kernel parameters or some serious system issue. It looks like the DragonflyBSD folks made a goal to do well on pgbench and got to the level of ~88% of linux with 80 clients. The important item that has been left out (or is just implied as OS level defaults) is sysctl/tunable variables set in the *BSD OSes (on DFly, FreeBSD, and NetBSD). Unfortunately (based on my experience) FreeBSD could be a lot better when it comes to defaults, and more tuning is required to get better performance. So if they're working with the OS defaults, this might not be a fair equivalent to the best performance that FreeBSD can yield, but it's probably fair to do this for the sake of repeatability and to prove what these OSes can do out of the box. This is in addition to the [lock] contention issues that jeffr@ and a few others are working on alleviating. FWIW, I think that the last time scheduler benchmarks from anyone at @FreeBSD.org (was kris@ the last one, or has flo@ run benchmarks since then? My Googling is a bit inconclusive) was run was several years ago as well, so if Linux has improved I'm not at all surprised. However, please also take into consideration that the hardware then and the hardware now are grossly different. So the interactions between the hardware then and the hardware now might differ greatly. In short, more inspection needs to be done to figure out whether or not the findings are true [with caveats] or false. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make -jN buildworld on 512MB ram
On Wed, Oct 31, 2012 at 12:58 PM, Alfred Perlstein bri...@mu.org wrote: It seems like the new compiler likes to get up to ~200+MB resident when building some basic things in our tree. Unfortunately this causes smaller machines (VMs) to take days because of swap thrashing. Doesn't our make(1) have some stuff to mitigate this? I would expect it to be a bit smarter about detecting the number of swaps/pages/faults of its children and taking into account the machine's total ram before forking off new processes. I know gmake has some algorithms, although last I checked they were very naive and didn't work well. Any ideas? I mean a really simple algorithm could be devised that would be better than what we appear to have (which is nothing). Even if an algorithm can't be come up with, why not something just to throttle the max number of c++/g++ processes thrown out. Maybe I'm missing a trick I can pull off with some make.conf knobs? Idk, summer of code idea? Anyone mentoring someone they want to have a look at this? FreeBSD make/bmake doesn't, but gmake sure does with --load [1]! I would ask sjg@ to be absolutely sure, but I don't see any getrlimit/setrlimit calls around the code, apart from RLIMIT_NOFILE. For now you have to tune your number of jobs appropriately.. HTH, -Garrett PS I feel your pain because I have a number of FreeBSD VMs with =2GB RAM. 1. http://www.gnu.org/software/make/manual/make.html#index-g_t_0040code_007b_002d_002dload_002daverage_007d-746 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
On Wed, Oct 31, 2012 at 12:06 PM, Konstantin Belousov kostik...@gmail.com wrote: ... If not wired, swapout might cause a delay of the next pat, leading to panic. Yes. We need to write microbenchmarks and do more careful analysis to figure out where and why things have grown. Maybe a mock daemon and application (single and multithreaded) would be a good start? There are some example programs in the open_posix_testsuite (see LTP) that might be good for at least getting non-daemon apps that use pthreads that can be used for instrumenting where and why things have changed. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: make -jN buildworld on 512MB ram
On Wed, Oct 31, 2012 at 1:44 PM, Adrian Chadd adr...@freebsd.org wrote: On 31 October 2012 13:41, Peter Jeremy pe...@rulingia.com wrote: Another, more involved, approach would be for the scheduler to manage groups of processes - if a group of processes is causing memory pressure as a whole then the scheduler just stops scheduling some of them until the pressure reduces (effectively swap them out). (Yes, that's vague and lots of hand-waving that might not be realisable). Well, does the compiler actually need that much memory? :) For calculating SSAs, directed graphs, and when dealing with larger optimization levels -- sadly, yes it can. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!)
On Sun, Oct 28, 2012 at 9:07 AM, Adrian Chadd adr...@freebsd.org wrote: On 28 October 2012 03:55, Gabor Kovesdan ga...@kovesdan.org wrote: Hi Hiren, good to hear that someone is working on this! However, porting these utilies is much tougher than it apparently seems. There are much more criteria than just it compiles and works. More specifically, you should make sure that: [snip] * It's totally bug compatible for now with gnu patch/diff. * You write a _lot_ of test cases for the test framework, so people can do automated regression testing on both performance and behaviour. It'd be nice to have more regression testing. :-) If you're looking for bug compatibility with GNU patch, I would start with the tests produced by upstream [1] as a base for determining how compatible BSD patch really is. Similar steps could and should have been done for BSD grep [2] (unfortunately GNU sort doesn't have any tests, but if we develop the guts (inputs and expected output) of some tests and commit them back to GNU, I'm sure they would appreciate it). Thanks, -Garrett 1. http://git.savannah.gnu.org/cgit/patch.git/tree/tests 2. http://git.savannah.gnu.org/cgit/grep.git/tree/tests ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Fri, Oct 26, 2012 at 9:34 AM, David O'Brien obr...@freebsd.org wrote: On Thu, Oct 25, 2012 at 03:00:21PM -0700, Garrett Cooper wrote: Here's an updated version of the workaround that works properly in all cases and installs bmake as make and links make to pmake when WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is specified (this works better than the previous patch I sent to Simon). Garrett, I don't see how this could be committed -- it will make it difficult for 10-CURRENT folks to build ports (and there are no pre-build packages for 10-CURRENT). I don't want it committed because Simon's move makes sense longterm: I wanted to offer an alternative as opposed to just being stuck in purgatory and figured that others might benefit from it. We're stuck at a point now that we need to make a break but we also need to ensure that we don't break things too badly for users with older versions of make. Installing our version of make as something other than `make` would at least allow us to use make as pmake in ports, but I realized it would requiring hacking around portmaster, portupgrade, and a number of other tools that expect FreeBSD make to be make and don't have a means of parameterizing make in the environment or on the command line. So looking back now my mitigation solution would not be ideal and would not fix any problems really. Are you not able to use this instead (w/WANT_USRBIN_BMAKE= in /etc/src.conf)? That would be interesting too (and is a lot less involved than my patch), and probably would have less fallout. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Fri, Oct 26, 2012 at 9:54 AM, David O'Brien obr...@freebsd.org wrote: On Tue, Oct 02, 2012 at 07:19:55AM -0700, Garrett Cooper wrote: Hmmm... that's one of the 3 approaches I provided, but it turned out ... 1. Test programs live with the sources (this was the requested approach), e.g. 2. Test programs live in subdirs: 3. Test programs completely decoupled from the source tree: Could someone please commit at least one working .c test and one .sh test? There is nothing to follow for others trying to write their own tests in the FreeBSD-way. I could not find a single consumer of ATF in HEAD. This makes it seem this is still a WIP that should be living in a branch and not in HEAD. But we're paying the price for checkout build times, etc... See the recent 9.1-R thread and Peter Wemm (and others) comments in this regard. (this is why I hadn't committed the WIP I had - it wasn't ready for HEAD) There are some basic examples, but they're in my p4 branch and unfortunately they depend on atf.test.mk/bsd.test.mk/bsd.progs.mk existing before they can be built (please see the Examples section in http://wiki.freebsd.org/TestingFreeBSD ). I also have the tests integrated in my perforce branch and running, but it doesn't do a bit of good unless the build pieces are in. I've been trying to get these things into HEAD in proper order so they can be used effectively. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
Minor disambiguation: On Fri, Oct 26, 2012 at 12:27 PM, Garrett Cooper yaneg...@gmail.com wrote: ... There are some basic examples, but they're in my p4 branch and unfortunately they depend on atf.test.mk/bsd.test.mk/bsd.progs.mk existing before they can be built (please see the Examples section in http://wiki.freebsd.org/TestingFreeBSD ). I also have the tests I also have the tests - I also have the ATF feature/integration tests integrated in my perforce branch and running, but it doesn't do a bit of good unless the build pieces are in. I've been trying to get these things into HEAD in proper order so they can be used effectively. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Fri, Oct 26, 2012 at 12:54 PM, Simon J. Gerraty s...@juniper.net wrote: On Fri, 26 Oct 2012 12:27:35 -0700, Garrett Cooper writes: There are some basic examples, but they're in my p4 branch and unfortunately they depend on atf.test.mk/bsd.test.mk/bsd.progs.mk Speaking of which. I notice there is now a bsd.progs.mk in head, which bears little relationship to the one I was talking about (from devel/bmake). Is this bsd.progs.mk essentially your port of netbsd's bsd.prog.mk it seems much more complex than should be necessary (my progs.mk is 75 lines vs 350 for the one in head). Yup. I was a bit surprised it was committed, but there might have been some confusion over what all was going to go in with the ATF port. Would you be awfully upset if I replace it with the simpler one? Nah. Feel free to nuke it and remove it from the build once you get progs.mk in proper shape; I'm more concerned about completing the atf.test.mk/bsd.test.mk snippets because once those are committed I can get the test example code and the integration test patches reviewed and committed. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 25, 2012 at 2:23 PM, Marcel Moolenaar mar...@xcllnt.net wrote: ... I think there are 2 reasons why not to: 1. The people working on ATF have not raised this concern and have expressed that using the WITH_BMAKE knob is but a small price to pay. So let's work the bmake side and be able to get rid of the knob as soon as possible. It is annoying with the magnitude of build-related errors, but I have a workaround. 2. More knobs isn't better -- we must have none of the knobs in the end, so the more we create, the more work we have to get rid of them. That's just more work spent not focusing on the task at hand and thus more time wasted. Yes, but not being able to update one's machine makes me sad panda. In short: this isn't a 2-knob problem by any stretch of the imagination. The real issue is that I need to take the patch Simon developed, run with it, and in parallel he needs to -- and hopefully already is -- engage portmgr to get it through a number of exp- runs to make sure bmake does what it's supposed to do with his patch. Backwards compatibility will need to be maintained for ports because ports has to work on multiple versions of FreeBSD [where bmake isn't yet available/present], so maybe a fork in the road for bsd.port.mk should be devised in order to make everything work. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Installing make as pmake when WITH_BMAKE specified (was Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program)
On Thu, Oct 25, 2012 at 2:32 PM, Garrett Cooper yaneg...@gmail.com wrote: ... The real issue is that I need to take the patch Simon developed, run with it, and in parallel he needs to -- and hopefully already is -- engage portmgr to get it through a number of exp- runs to make sure bmake does what it's supposed to do with his patch. Backwards compatibility will need to be maintained for ports because ports has to work on multiple versions of FreeBSD [where bmake isn't yet available/present], so maybe a fork in the road for bsd.port.mk should be devised in order to make everything work. Here's an updated version of the workaround that works properly in all cases and installs bmake as make and links make to pmake when WITH_BMAKE=yes, and installs make as make when WITHOUT_BMAKE is specified (this works better than the previous patch I sent to Simon). The point of the patch isn't to discourage bmake use; in fact this encourages bmake use more because I'm able to use bmake as my system make, but be able to fall back to pmake as needed. Thanks! -Garrett install-make-as-pmake-when-WITH_BMAKE-specified.patch Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 25, 2012 at 3:01 PM, Chris Rees cr...@freebsd.org wrote: ... Now you've terrified me, and probably most other ports people too. Is there a Wiki page where the actual benefits of moving to bmake are made clear? This is a major, *major* upheaval, and having two versions of bsd.port.mk for years is simply not an option. I'm not the best advocate for bmake vs pmake; like bapt@ said in the followup email, most things work out of the box where people aren't trying to be clever, but I've found some interesting edgecases where bmake works and pmake doesn't, and vice versa because the old code depends upon incorrect behavior. I wasn't necessarily advocating having two bsd.*.mk files as the best idea -- it's just what came to mind first. Have you discussed this on ports@? I haven't, but I hope that someone else started this discussion... Thanks, -Garrett PS I am an optimist, but I'm a realist more than an optimist. I know that changing major/fundamental system components like make, the toolchain, etc requires a good deal of testing and there will be bugs/issues that need to be resolved. We just should make sure that things work as best possible for those looking back as well as those looking forward because it's considerably easier doing development on FreeBSD when I can just update a ports tree, build on 6.x/7.2/7.3, run some quick tests, then switch up to 10 and do other development. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Sat, Oct 13, 2012 at 1:13 PM, Simon J. Gerraty s...@juniper.net wrote: On Sat, 13 Oct 2012 15:15:59 -0400, George Neville-Neil writes: It could be a while (many weeks) before we get to 4, so the question really is whether the people working on ATF are willing and able to build and install FreeBSD using WITH_BMAKE? I think that's a small price to pay for getting going with the ATF stuff now rather than in 4 weeks. What's the right way to do this now with HEAD? We can add bsd.progs.mk (if you have devel/bmake port installed you have it as /usr/local/share/mk/progs.mk) and atf.test.mk and people can just go for it ? As long as it can function sanely in a NetBSD-like manner and I can start writing tests, I don't mind... Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: problem cross-compiling 9.1
On Oct 9, 2012, at 3:46 AM, Daniel Braniss da...@cs.huji.ac.il wrote: [snip] any fix? You have found the fix. Remove the WITHOUT_ options from the build that keep it from completing. You'll be able to add them at installworld time w/o a hassle. nanobsd uses this to keep things down, while still being able to build the system. Warner where can I find the with/without list? btw, I did look at nanobsd in the past and have borrowed some ideas :-) man make.conf and man src.conf, then read through bsd.own.mk if interested in knowing what exactly can be used. HTH! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Tue, Oct 2, 2012 at 7:37 AM, John Baldwin j...@freebsd.org wrote: On Tuesday, October 02, 2012 10:29:49 am Garrett Cooper wrote: On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin j...@freebsd.org wrote: ... This sounds like a superior approach. It doesn't break any current use cases while giving the ability to build multiple programs in the few places that need it. It sounds like there are a few places under gnu/ from Garrett's reply that might be able to make use of this as well. For the record, gnu/cc/cc_tools/Makefile is where I first spotted a potential bsd.progs.mk candidate. Most of the other code doesn't care given how things are organized in our source tree. BTW, one general comment. There seem to be two completely independent groups of folks working on ATF (e.g. there have been two different imports of ATF into the tree in two different locations IIRC, and now we have two different sets of patches to our system makefiles). Are these two groups talking to each other at all? I know in May that many folks (certainly multiple vendors) are interested in ATF, and it seems that both Juniper and Isilon have ported ATF internally. It seems that it might be good for the two groups to work together to avoid stomping on each other's toes. It seems there are some differences in the two approaches that merit working out to avoid a lot of wasted effort on both sides. Both parties (Isilon/Juniper) are converging on the ATF porting work that Giorgos/myself have done after talking at the FreeBSD Foundation meet-n-greet. I have contributed all of the patches that I have other to marcel for feedback. This is very non-obvious to the public at large (e.g. there was no public response to one group's inquiry about the second ATF import for example). Also, given that you had no idea that sgf@ and obrien@ were working on importing NetBSD's bmake as a prerequisite for ATF, it seems that whatever discussions were held were not very detailed at best. I think it would be good to have the various folks working on ATF to at least summarize the current state of things and sketch out some sort of plan or roadmap for future work in a public forum (such as atf@, though a summary mail would be quite appropriate for arch@). I'm in part to blame for this. There was some discussion -- but not at length; unfortunately no one from Juniper was present at the meet and greet; the information I got was second hand; I didn't follow up to figure out the exact details / clarify what I had in mind with the appropriate parties. That being said, I *sort* of understand what's going on now, although I'm still guessing as I haven't received any FreeBSD internal (developers@, etc) emails and all the discussion I have so far is between gnn@, marcel@, gibbs@, mlaier@, and mdf@. For all intents and purposes I've been paused for a few weeks because of other things, so no harm, no foul, but I'd like to know what all is being contributed back from Juniper in terms of tests, ATF integration into the build system (which I've given back to marcel@/gnn@, but haven't received feedback for yet -- probably because they're busy), etc so I can better avoid duplicated effort and help the cause of creating a maintainable/testable FreeBSD. As far as what Isilon is contributing back, I wouldn't look any further than my perforce repo; the original goal as of last BSDCan was to contribute back `isi_check` (custom wrapper around GNU libcheck), and maybe some of our tests are written for isi_check: the problem with that plan is that it depends on GNU [lib]check -- yet another test infrastructure -- diverges us more unnecessarily from NetBSD (and there are several things we want to grab from NetBSD and contribute back instead of forging ahead down our own path), the tests would need to be audited and cleaned up to use generic macros and check for generic functionality, etc. Also, it would help to have generic system tests similar to LTP's breadth in the tree (so that way we can avoid breakage before things are committed to current). There are some functional gaps that I like to fill in with ATF that GNU libcheck does well [with fixtures] and there are some inconsistencies between the ATF C and C++ bindings I'm working on enhancing More details about what I planned on doing can be found here: http://wiki.freebsd.org/TestingFreeBSD -- although it deserves updating when looking at the structure and dealing with the patches (I need to update it to just work with the latest current). Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Thu, Oct 4, 2012 at 9:29 AM, David Wolfskill da...@catwhisker.org wrote: On Thu, Oct 04, 2012 at 12:11:21PM -0400, George Neville-Neil wrote: ... But, I would like to drive this to a solution on arch@. We don't have an atf@, but we do have a test@ and testing@. We have too many mailing lists already, so let's finish this up here if we can and then continue talking on testing@. ... Before folks get too excited about test@ testing@: * test@ is for testing ability to send mail to FreeBSD.org (mailing lists). * testing@ *used* to exist, but was retired for lack of relevant traffic. * There's little difference in effort in resurrecting testing@ vs. creating atf@. I think that resurrecting testing@ makes more sense as creating an atf specific list seems a bit too focused on ATF, primarily because atf is being partially superseded by kyua (pronounced Q-A) in the near future. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Mon, Oct 1, 2012 at 5:00 PM, Simon J. Gerraty s...@juniper.net wrote: Not to mention the fact that bsd.prog.mk goes from being relatively simple, to unspeakably hard to read, and all for rather limited = return. This btw I think is the more important issue. I was looking at bsd.prog.mk in netbsd the other day. It has no business being that complex. Ok. Even though I originally thought that my changes were a bit hacky for not modifying bsd.man.mk, bsd.nls.mk, etc, looking back the way they were resolved was a little elegant in its simplicity (albeit not optimized). ... It order to do this, I need to be able to build multiple programs so = things are as transparent. On the flipside, bsd.prog[s].mk can live on = We put the test cases in a subdir of the lib/prog This has multiple benefits, and eliminates any impact on the normal build of said libs/progs. Hmmm... that's one of the 3 approaches I provided, but it turned out to be annoying to make this work at first inspection because of how things were done in our build system. Just for review (even though it's OT), the three approaches I presented were as follows... Note: in all 3 examples, clock.c is the source code and t_clock.c is the relevant unittest code. 1. Test programs live with the sources (this was the requested approach), e.g. lib/libc/gen/... .../clock.c .../t_clock.c 2. Test programs live in subdirs: lib/libc/gen/... .../clock.c .../tests/... .../t_clock.c 3. Test programs completely decoupled from the source tree: lib/libc/gen/... .../clock.c tests/lib/libc/gen/... .../t_clock.c A hybrid approach (1.+3. / 2.+3.) should probably be used anyhow for stress tests and the like that really have no business living in one particular directory in the source tree (sort of achieving what tools/regression does today, but hopefully in a less messy manner as tools/regression appears to have grown organically minus any single sane order). Also a number of our teams find it necessary to create mock classes etc to adequately test their libs. Keeping all this in a tests/ subdir makes it easy, to keep things neat up to date, and ensure that the tests pass. Trying to do all that in the same dir as the lib would be ugly. This (consolidating everything under a single directory) is the way that was requested by the beforementioned parties. FWIW we use progs.mk (as bsd.progs.mk) from ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/mk-*.tar.gz=20 It isn't ideal, but it certainly avoids a lot of churn and complexity for what is essentially a corner case. This requires pulling bmake into FreeBSD proper in order for things to = function the last I checked as bsd.prog.mk depends upon bmake directives = This is already happening ;-) I wish I had known that. I pinged marcel/obrien about this some weeks ago and didn't receive a response. Originally bsd.progs.mk was going to be a home grown effort that was going to be killed off and replaced with NetBSD's build infrastructure, but I didn't get a reply and had to put this (my work to replace bsd.prog.mk) plan in motion given requests I was provided above for resolving the source/unittest code consolidation effort. Ideally however, I would like doing this compared to running a custom = build infrastructure, but (as you probably know) this requires = rototilling the current FreeBSD build system to a large degree = Actually building FreeBSD-current using bmake requires only modest changes. Yes for the most part, and I agree that bmake is definitely more advanced than FreeBSD pmake so I consider it a very welcome change. What are the plans for importing bmake into FreeBSD (this should probably be a different thread)? ... I know, but it is a very useful thing to be able to do. You can add knobs to control such things of course. I agree that it's a good thing (in theory) -- it'd just help to discuss this with Julio first because I know of a couple cases where this would be unusable given how bsd.test.mk is coded: 1. The it works for me on my machine! certification: It encourages environment tainting, which could be a really, really bad thing; I've seen developers take interesting shortcuts when testing their code (me included sometimes :)..); I've seen hardcoded paths, harcoded paths for named semaphores, things that just work because of someone's host environment, feature specific assumptions (developer X was doing testing on feature Y and things broke when he/she committed the testcase to head), etc where the it works for me on my machine! certification would be true more often than not. These same individuals would more likely than not execute things taking shortcuts, but I want to avoid creating a system where developers cut corners and commit too early because working within the confines of the system is not conducive to getting work done. 2. Failure
Re: Fwd: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Tue, Oct 2, 2012 at 4:50 AM, John Baldwin j...@freebsd.org wrote: ... This sounds like a superior approach. It doesn't break any current use cases while giving the ability to build multiple programs in the few places that need it. It sounds like there are a few places under gnu/ from Garrett's reply that might be able to make use of this as well. For the record, gnu/cc/cc_tools/Makefile is where I first spotted a potential bsd.progs.mk candidate. Most of the other code doesn't care given how things are organized in our source tree. BTW, one general comment. There seem to be two completely independent groups of folks working on ATF (e.g. there have been two different imports of ATF into the tree in two different locations IIRC, and now we have two different sets of patches to our system makefiles). Are these two groups talking to each other at all? I know in May that many folks (certainly multiple vendors) are interested in ATF, and it seems that both Juniper and Isilon have ported ATF internally. It seems that it might be good for the two groups to work together to avoid stomping on each other's toes. It seems there are some differences in the two approaches that merit working out to avoid a lot of wasted effort on both sides. Both parties (Isilon/Juniper) are converging on the ATF porting work that Giorgos/myself have done after talking at the FreeBSD Foundation meet-n-greet. I have contributed all of the patches that I have other to marcel for feedback. Do we already have a freebsd-atf@ mailing list? If not, perhaps we should create one and start these discussions there? Probably wouldn't be a bad idea as I'm currently suspended a bit waiting on feedback for how to proceed; too bad freebsd-test is being used for other things :).. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
Hi Simon! On Oct 1, 2012, at 3:31 PM, Simon J. Gerraty wrote: Hi Garrett, From: Garrett Cooper yaneg...@gmail.com Subject: [CFT/RFC]: refactor bsd.prog.mk to understand multiple = programs instead of a singular program Date: September 2, 2012 11:01:09 PM PDT To: freebsd-hackers@freebsd.org Cc: freebsd-a...@freebsd.org Arch freebsd-a...@freebsd.org =20 Hello, I've been a bit busy working on porting over ATF from NetBSD, and Thanks, we've been using ATF in Junos for a while and glad to see it being imported to FreeBSD. Thanks (and I appreciate the help marcel@ has given by taking the first step in importing it). one of the pieces that's currently not available in FreeBSD that's available in NetBSD is the ability to understand and compile multiple programs. In order to do this I had to refactor bsd.prog.mk (a lot). A change like this to bsd.prog.mk can have considerable fallout. Eg. any makefile that tweaks OBJS is suddenly out of luck. Well… any Makefiles attempting to be clever (e.g. crunchgen) are out of luck and would need to change. Most [include] Makefiles will see virtually no change. Not to mention the fact that bsd.prog.mk goes from being relatively simple, to unspeakably hard to read, and all for rather limited return. I sort of tried to match bsd.prog.mk in NetBSD in the beginning, but things diverged from there… I'm sure things could be made more readable so any comments would be much appreciated :)! Apart from ATF, is there any huge demand for building multiple progs in the same directory? Well, I noticed that there are a couple ugly messes in the gnu/... directory that attempt to work around the fact that bsd.prog.mk doesn't support more than one program by being tricky and emulating bsd.prog.mk instead of solving the generic problem (and once I got over that compatibility issue I stopped tracking this class of consumer). Most consumers don't care (they split up programs into different directories or use hardlink hacks/basename detection to differentiate one program functionally from another). Getting back to the idea at hand, the enhancement goal was to get the testcases to live [and optionally be built/installed] with the source code to avoid bitrot; I know this isn't the current NetBSD design, but this is what was requested be done by gnn, marcel, and mdf, and I agree. It order to do this, I need to be able to build multiple programs so things are as transparent. On the flipside, bsd.prog[s].mk can live on its own, be pulled in automatically by bsd.test.mk, and that would be it. This encourages code duplication though and bugs can persist in either Makefile, when I'd rather work out all the kinks in whatever succeeds the legacy bsd.prog.mk file. FWIW we use progs.mk (as bsd.progs.mk) from ftp://ftp.netbsd.org/pub/NetBSD/misc/sjg/mk-*.tar.gz It isn't ideal, but it certainly avoids a lot of churn and complexity for what is essentially a corner case. This requires pulling bmake into FreeBSD proper in order for things to function the last I checked as bsd.prog.mk depends upon bmake directives in order to function properly 100% of the time (and there are external dependencies and assumptions one has to deal with when using bsd.prog.mk, etc from NetBSD that made that a bit of a no-go without refactoring/pulling in bits from NetBSD). I could be wrong though, so please let me know if I am :). Ideally however, I would like doing this compared to running a custom build infrastructure, but (as you probably know) this requires rototilling the current FreeBSD build system to a large degree (definitely not impossible… just needs time and effort). We have an atf.test.mk which leverages that. It also handles automatically running the tests if building for the host. This allows us to fail the build if any unit-tests do not pass. Hmm… that wasn't really the end-goal of bsd.test.mk based on my reading, but I'm sure Julio would be interested in it. I need to do adjusting in order to allow automatically executing testcases compatible to the host architecture, but that isn't hard to do (no more than a couple hours work). Note, atf.test.mk is loosely derrived from NetBSD's bsd.tests.mk, but named for what it is (ATF specific tests) since we wanted the flexibility to have more than one test framework. bsd.test.mk in NetBSD isn't completely test-agnostic, but it isn't entirely ATF centric either. I'm trying not to stray too far from NetBSD in this area because there really isn't any reason to do so. FWIW I'd like to see other test frameworks (lua, unittest//nose, etc) just snap into bsd.test.mk as easily as possible as it would make some groups lives easier, but that requires a bit more thought for another day. Thanks for the feedback! -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Sep 24, 2012, at 1:21 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cagh67wqty4krgwspa5jaht-4hqd4veykley-r3c6k9f5xaf...@mail.gmail.com , Garrett Cooper writes: No difference proven at 95.0% confidence This is the important bit of information... Yeah.. It's been a few moons since I've taken statistics. Some other pieces of data: This was done with... - testing was done multiuser on a lightly loaded system. - build was done with -j24 on a my workstation with 4 SMT enabled cores. - the scratch disk is ata enabled, whereas the sources were housed on an mfi backed disk. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Sat, Sep 22, 2012 at 11:30 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message cagh67wsux7zjrtb5gehqwhkqykog-atwkinw5csjlrzftzk...@mail.gmail.com , Garrett Cooper writes: Without the change: $ python calc_runtime.py bw.*_without.log | ministat -w 72 [...] $ python calc_runtime.py bw.*.log | ministat -w 72 Try: python calc_runtime.py bw.*_without.log _without python calc_runtime.py bw.*.log _with ministat -w 72 _with _without :-) (PS: your two chosen glob patterns are not exclusive, but I suppose that was for illustration only) Forgot to mention that I ran the with results before the without results, so technically the files didn't exist yet and hence the results are separate. But, just for absolute clarity for archiving sake (and provided your suggestion on how to overlay both graphs), here are the results: $ for i in bw.*[0-9].log; do mv $i `echo $i | sed -e 's/\.log/_with\.log/g'`; done $ python calc_runtime.py bw.*_with.log _with $ python calc_runtime.py bw.*_without.log _without $ ministat -w 72 _with _without x _with + _without ++ | +x | |++ + xx + x xx+ ++ x x +xx +| | ||A_MA___M___|__| | ++ N Min MaxMedian AvgStddev x 10 940 1002 988 972.3 24.476973 + 10 919 1010 972 958.9 33.994934 No difference proven at 95.0% confidence Thanks for the tip :)! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
On Sun, Sep 2, 2012 at 11:01 PM, Garrett Cooper yaneg...@gmail.com wrote:
Hello,
I've been a bit busy working on porting over ATF from NetBSD, and
one of the pieces that's currently not available in FreeBSD that's
available in NetBSD is the ability to understand and compile multiple
programs. In order to do this I had to refactor bsd.prog.mk (a lot).
The attached patch is the end result so far, and I was wondering if
anyone could please review it and/or test it (outside of me doing so).
I wrote over 40 tests, but it's not exercising everything, and I would
like for someone to please review/test this out who has an interest in
NLS support (ala bsd.nls.mk) in particular. AFAICT this is the only
gap that I couldn't resolve right away (there isn't a ton of recent
documentation on how to use bsd.nls.mk).
I'll run a micro benchmark and buildworld a few times (in
progress) with and without the change to measure the performance
effect.
Any assistance would be much appreciated.
I've attached an updated version of the patch (run through
buildworld successfully multiple times; make universe successfully;
going to submit for an -exp run). I needed to modify bsd.crunchgen.mk
to grok OBJS.${PROG}, but apart from that backwards compatibility has
been maintained -- sans-INSTALLFLAGS_EDIT (does anyone still use that
undocumented functionality?).
Performance wise, it's slightly slower on my W3520 with the
change, but not by much (~20 seconds).
As always, questions and comments are welcome, and if someone has
a chance, please review the proposed patch.
Thanks!
-Garrett
Without the change:
$ python calc_runtime.py bw.*_without.log | ministat -w 72
x stdin
++
| x |
|xx x x x xx x x|
| |_A_M| |
++
N Min MaxMedian AvgStddev
x 10 919 1010 972 958.9 33.994934
With the change:
$ python calc_runtime.py bw.*.log | ministat -w 72
x stdin
++
| x|
|xx xx x x x xx|
| |___A_M_| |
++
N Min MaxMedian AvgStddev
x 10 940 1002 988 972.3 24.476973
make universe results:
# make universe MAKE_JUST_WORLDS=y
--
make universe started on Tue Sep 18 09:30:04 PDT 2012
--
amd64 started on Tue Sep 18 09:30:04 PDT 2012
amd64.amd64 buildworld started on Tue Sep 18 09:30:04 PDT 2012
amd64.amd64 buildworld completed on Tue Sep 18 11:20:19 PDT 2012
amd64 completed on Tue Sep 18 11:20:19 PDT 2012
arm started on Tue Sep 18 11:20:19 PDT 2012
arm.arm buildworld started on Tue Sep 18 11:20:19 PDT 2012
arm.arm buildworld completed on Tue Sep 18 12:25:24 PDT 2012
arm.armeb buildworld started on Tue Sep 18 12:25:24 PDT 2012
arm.armeb buildworld completed on Tue Sep 18 13:30:25 PDT 2012
arm.armv6 buildworld started on Tue Sep 18 13:30:25 PDT 2012
arm.armv6 buildworld completed on Tue Sep 18 14:35:14 PDT 2012
arm.armv6eb buildworld started on Tue Sep 18 14:35:14 PDT 2012
arm.armv6eb buildworld completed on Tue Sep 18 15:40:05 PDT 2012
arm completed on Tue Sep 18 15:40:05 PDT 2012
i386 started on Tue Sep 18 15:40:05 PDT 2012
i386.i386 buildworld started on Tue Sep 18 15:40:05 PDT 2012
i386.i386 buildworld completed on Tue Sep 18 16:56:06 PDT 2012
i386 completed on Tue Sep 18 16:56:06 PDT 2012
ia64 started on Tue Sep 18 16:56:06 PDT 2012
ia64.ia64 buildworld started on Tue Sep 18 16:56:06 PDT 2012
ia64.ia64 buildworld completed on Tue Sep 18 18:27:49 PDT 2012
ia64 completed on Tue Sep 18 18:27:49 PDT 2012
mips started on Tue Sep 18 18:27:49 PDT 2012
mips.mipsel buildworld started on Tue Sep 18 18:27:49 PDT 2012
mips.mipsel buildworld completed on Tue Sep 18 19:34:50 PDT 2012
mips.mips buildworld started on Tue Sep 18 19:34:50 PDT 2012
mips.mips buildworld completed on Tue Sep 18 20:41:49 PDT 2012
mips.mips64el buildworld started on Tue Sep 18 20:41:49 PDT 2012
mips.mips64el buildworld completed on Tue Sep 18 21:49:21 PDT 2012
mips.mips64 buildworld started on Tue Sep 18 21:49:21 PDT 2012
mips.mips64 buildworld completed on Tue Sep 18 22:57:13 PDT 2012
mips.mipsn32 buildworld started on Tue Sep 18 22:57:13 PDT 2012
mips.mipsn32 buildworld
Re: NDEBUG and assert()
On Wed, Sep 19, 2012 at 3:18 AM, Erik Cederstrand e...@cederstrand.dk wrote: Den 19/09/2012 kl. 11.19 skrev Erik Cederstrand e...@cederstrand.dk: The below below patch will let the analyzer reason correctly about the code, and removes the report mentioned above (and a handful others in ncurses). It doesn't touch contrib code, but I'm not happy about changing include/assert.h since it's used so many other places. Any other ideas for how to best solve this? An alternative that doesn't touch assert.h but contains a patch to /contrib: This should be disabled [in part because it can be properly enabled with WITH_ASSERT_DEBUG=yes in /etc/src.conf]. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Providing a default graphical environment on FreeBSD
On Mon, Sep 17, 2012 at 8:35 AM, Lorenzo Cogotti miciam...@hotmail.it wrote: Hi, ... Replying more to the Wayland comments, yes.. FreeBSD/NetBSD/OpenBSD need to implement the Wayland `protocol` because xorg-server development is slowly being killed over time, but unfortunately that work is not slotted by anyone directly affiliated with the project AFAIK. The project is also beta though, and as many know the new hotness in Linux generally has a short lifespan unless it's truly well thought out, so I think waiting and seeing what happens (but observing with interest and participating in discussions are necessary) would be a better use of resources instead of immediately immersing FreeBSD into Linux-style development churn. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Providing a default graphical environment on FreeBSD
On Mon, Sep 17, 2012 at 11:09 AM, Zhihao Yuan lich...@gmail.com wrote: On Mon, Sep 17, 2012 at 1:05 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message CAGsORuBqiodwt_EmVqB+fO=tgOVeZOERopSE2y=mla8jp6z...@mail.gmail.com , Zhihao Yuan writes: Well, let's make it more straightforward. I hope people can agree with this: a default, officially supported modern desktop environment is essential to FreeBSD. No, it is not. It would certainly be nice to have as an option, but I would hate to have to deal with it, when I squeeze FreeBSD into embedded systems which have neither graphics outputs nor keyboard or mouse inputs. Default does not mean you have to install it. Default means when you are looking for a DE, bsdinstall, handbook, official site, all of them answers *DE. *gathers breath for really tangential/OT rant* joking Sounds like we have someone volunteering to write a chapter in the handbook and do some X11 development to make Gnome, KDE, XFCE, LXDE, Fluxbox, [...], or etc work better on FreeBSD! /joking To be succinct: this is not OSX/Windows. True Unix and Unix clones can be decoupled from a desktop environment enough that forcing everyone to have one choice for desktop user experience doesn't make sense, and the fact that there isn't a common GUI development toolkit (GTK, QT, etc) encourages fragmentation of effort further (I think it's called the Bazaar model of development :P). It honestly sounds like what you're looking for is a custom FreeBSD-based distribution (and PCBSD is one of those options) as FreeBSD is a generic project. Even the Linux kernel//GNU/Linux OS doesn't have a single adopted DE as its flagship DE. With all of the choices I listed above (and more), getting everyone to agree on working with one DE is like herding cats, in part because end-users/developers have different requirements, opinions, work styles, etc. It makes more sense to provide hooks into several DEs (like Linux, PCBSD, etc has done) to accomplish various tasks in a GUI-ish manner (setting up networking, wireless, etc) and upstream those changes if and when one has the chance to do so. Finally, one should then become a devoted testing resource/advocate FreeBSD OS integration in the future if one has interest in continuing to use said DE on FreeBSD. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Providing a default graphical environment on FreeBSD
On Mon, Sep 17, 2012 at 12:01 PM, Lorenzo Cogotti miciam...@hotmail.it wrote: Il 17/09/2012 20:32, Garrett Cooper ha scritto: *gathers breath for really tangential/OT rant* joking Sounds like we have someone volunteering to write a chapter in the handbook and do some X11 development to make Gnome, KDE, XFCE, LXDE, Fluxbox, [...], or etc work better on FreeBSD! /joking If I proposed it, is because I'm willing to offer my help implementing my idea if it gets attention :-) To be succinct: this is not OSX/Windows. True Unix and Unix clones can be decoupled from a desktop environment enough that forcing everyone to have one choice for desktop user experience doesn't make sense, and the fact that there isn't a common GUI development toolkit (GTK, QT, etc) encourages fragmentation of effort further (I think it's called the Bazaar model of development :P). As I tried to make clear, I *don't want* to limit user's freedom in any way, nor getting away UNIX philosophy in any way from FreeBSD, nor trying to remove servers or other desktop environments solutions in any way. Solaris and other UNIces had CDE as their default environment, this was not preventing a perfectly written toolkit that used X server to run there, it wasn't preventing users from tearing away the GUI part and using it without it. My only objective is estabilishing a standard, just saying you want to make a GUI application for FreeBSD? You are asking yourself what desktop environment will work for sure on FreeBSD? There you have it, Blah DE works just well and is perfectly documented. ... To cut things short because this is really turning into a bikeshed: go talk to the folks at PCBSD. They are interested in using providing a graphically oriented version of FreeBSD and have multiple DEs distributed with their custom FreeBSD distribution. See if you can work with them to achieve your goals and then upstream the result to the upstream maintainers, or create a subproject that can be used in ports and/or elsewhere, then work with the PCBSD/FreeBSD devs to integrate your work into ports. I'm also sure that if you have something that hasn't been developed yet that's useful you will get more than a handful of Linux-oriented devs who will be interested in assisting you in making the application/applet available in more than one OS. Thanks, -Garrett PS It's not that I don't care about the effort (I run straight FreeBSD with fluxbox/X11 on my workstation at $work and my Netbook), but unless people put their money where their mouth is, this will just turn into another it would be nice to have FreeBSD do X-Y-Z threads that have not actually resulted in anything actually changing :(... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [RFC] Add *.orig/*.rej to svn:ignore in src?
On Sun, Sep 16, 2012 at 8:02 AM, Chris Rees cr...@freebsd.org wrote: On 16 September 2012 10:11, Garrett Cooper yaneg...@gmail.com wrote: I noticed that we have a handful of patterns currently ignored in svn:ignore (at least at the top-level… the lower levels don't appear to be set in any particular manner): $ svn propget svn:ignore _.tinderbox.* _.amd64.* _.arm.* _.i386.* _.ia64.* _.mips.* _.pc98.* _.powerpc.* _.sparc64.* _.sun4v.* $ svn info | grep URL: URL: http://svn.freebsd.org/base/head I was wondering if *.orig and *.rej should be added to the list as well to avoid checking in patch `artifact` files? Do you have an example where this has happened? I don't offhand; it was just a hypothetical issue that I considered might occur in the future if someone wasn't careful. Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[RFC] Add *.orig/*.rej to svn:ignore in src?
I noticed that we have a handful of patterns currently ignored in svn:ignore (at least at the top-level… the lower levels don't appear to be set in any particular manner): $ svn propget svn:ignore _.tinderbox.* _.amd64.* _.arm.* _.i386.* _.ia64.* _.mips.* _.pc98.* _.powerpc.* _.sparc64.* _.sun4v.* $ svn info | grep URL: URL: http://svn.freebsd.org/base/head I was wondering if *.orig and *.rej should be added to the list as well to avoid checking in patch `artifact` files? Thanks! -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why fdisk can't open root disk with MBR for writing?
On Sat, Sep 15, 2012 at 11:49 AM, Benjamin Kaduk ka...@mit.edu wrote: On Sat, 15 Sep 2012, Julian H. Stacey wrote: I have been applying this diff to my man fdisk: http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/sbin/fdisk/ *** 8.0-RELEASE/src/sbin/fdisk/fdisk.8 Sat Mar 14 22:32:16 2009 --- new-generic/src/sbin/fdisk/fdisk.8 Sat Mar 14 22:35:10 2009 *** *** 462,464 --- 462,468 The .Xr bsdlabel 8 command must be used for this. + .Pp + When running multi user, you cannot write unless you first run this: + .br + sysctl kern.geom.debugflags=16 I never submitted it as a send-pr, anyone think I should submit it to help save people ? We have had a long discussion about kern.geom.debugflags starting here: http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028090.html My understanding from that discussion is that your patch should not be accepted. Correct. Either fdisk should be fixed or updated to point out that gpart should be used. There is some useful utility for fdisk still, but it's waning. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why fdisk can't open root disk with MBR for writing?
On Fri, Sep 14, 2012 at 5:19 PM, Yuri y...@rawbw.com wrote: I am trying to change the active partition in MBR. This should be a matter of changing only two bits (clearing one in one byte and setting another one in another byte). However, fdisk complains: fdisk: Failed to write MBR. Try to use gpart(8). truss reveals that fdisk failed to open the root disk for writing: open(/dev/ad4,O_RDWR,00) ERR#1 'Operation not permitted' open(/dev/ad4,O_RDONLY,00) = 3 (0x3) ... ... pwrite(0x3,0x34048200,0x200,0x0,0x0,0x0) ERR#9 'Bad file descriptor' Failed to write MBR. Try to use gpart(8) The question is: why the disk can't be open RW under root? The secondary issue is the bug in fdisk: once -a option is supplied and it can't open it RW it should just say so, and not suggest using gpart because gpart will probably have the same issue. 1. What version of FreeBSD? 2. What do you have set for kern.geom.debug_flags? 3. Is /dev/ad4 (or any partitions / slices under it) currently in use? Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program
Hello, I've been a bit busy working on porting over ATF from NetBSD, and one of the pieces that's currently not available in FreeBSD that's available in NetBSD is the ability to understand and compile multiple programs. In order to do this I had to refactor bsd.prog.mk (a lot). The attached patch is the end result so far, and I was wondering if anyone could please review it and/or test it (outside of me doing so). I wrote over 40 tests, but it's not exercising everything, and I would like for someone to please review/test this out who has an interest in NLS support (ala bsd.nls.mk) in particular. AFAICT this is the only gap that I couldn't resolve right away (there isn't a ton of recent documentation on how to use bsd.nls.mk). I'll run a micro benchmark and buildworld a few times (in progress) with and without the change to measure the performance effect. Any assistance would be much appreciated. Thanks! -Garrett share-mk-bsd-prog-mk-CURRENT.patch Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] head/Makefile.inc1: Fix 'make distributeworld' when defining WITHOUT_GAMES
On Sun, Sep 2, 2012 at 2:46 PM, Glen Barber g...@freebsd.org wrote:
Hi,
Attached patch fixes 'make distributeworld' and our 'make release'
scripts when WITHOUT_GAMES is set.
Can someone please comment/test/commit?
It should be `.if ${MK_GAMES} != no`. Other than that, LGTM!
Thanks!
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] head/Makefile.inc1: Fix 'make distributeworld' when defining WITHOUT_GAMES
On Sun, Sep 2, 2012 at 3:05 PM, Garrett Cooper yaneg...@gmail.com wrote:
On Sun, Sep 2, 2012 at 2:46 PM, Glen Barber g...@freebsd.org wrote:
Hi,
Attached patch fixes 'make distributeworld' and our 'make release'
scripts when WITHOUT_GAMES is set.
Can someone please comment/test/commit?
It should be `.if ${MK_GAMES} != no`. Other than that, LGTM!
I would also dare to go one step further and remove
`${WORLDTMP}/legacy/usr/games` from BPATH and XPATH when ${MK_GAMES}
== no to reduce the number of path lookups done (this should help
speed up the build a bit).
Thanks!
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] head/Makefile.inc1: Fix 'make distributeworld' when defining WITHOUT_GAMES
On Sun, Sep 2, 2012 at 3:52 PM, Glen Barber g...@freebsd.org wrote:
On Sun, Sep 02, 2012 at 03:12:01PM -0700, Garrett Cooper wrote:
On Sun, Sep 2, 2012 at 3:05 PM, Garrett Cooper yaneg...@gmail.com wrote:
On Sun, Sep 2, 2012 at 2:46 PM, Glen Barber g...@freebsd.org wrote:
Hi,
Attached patch fixes 'make distributeworld' and our 'make release'
scripts when WITHOUT_GAMES is set.
Can someone please comment/test/commit?
It should be `.if ${MK_GAMES} != no`. Other than that, LGTM!
You're right, thanks. New diff attached.
Cool|! Too bad we don't have a publicly advertised MK_DOC knob --
otherwise doc would be an optional EXTRA_DISTRIBUTION as well (there's
an undocumented NODOC knob in release/Makefile) (yes bde@ -- feel free
to cringe at gmail's suckage with column wrapping).
Index: /usr/src/Makefile.inc1
===
--- /usr/src/Makefile.inc1 (revision 239292)
+++ /usr/src/Makefile.inc1 (working copy)
@@ -640,7 +640,13 @@
#
# Non-base distributions produced by the base system
-EXTRA_DISTRIBUTIONS= doc games
+EXTRA_DISTRIBUTIONS=
+.if ${MK_DOC} != no
+EXTRA_DISTRIBUTIONS+= doc
+.endif
+.if ${MK_GAMES} != no
+EXTRA_DISTRIBUTIONS+= games
+.endif
.if defined(LIB32TMP) ${MK_LIB32} != no
EXTRA_DISTRIBUTIONS+= lib32
.endif
I would also dare to go one step further and remove
`${WORLDTMP}/legacy/usr/games` from BPATH and XPATH when ${MK_GAMES}
== no to reduce the number of path lookups done (this should help
speed up the build a bit).
Considering how many problems I am finding in our 'make release' build
infrastructure, I would rather not do anything daringly right away. I
would rather fix the bugs I am finding, be sure things are not broken
differently, and then we can further fix things.
Sure.
Thank you for the suggestion.
No problem!
Thanks!
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: syslog(3) issues
On Sun, Sep 2, 2012 at 4:35 PM, Attilio Rao atti...@freebsd.org wrote: Hi, I was trying to use syslog(3) in a port application that uses threading , having all of them at the LOG_CRIT level. What I see is that when the logging gets massive (1000 entries) I cannot find some items within the /var/log/messages (I know because I started stamping also some sort of message ID in order to see what is going on). The missing items are in the order of 25% of what really be there. Someone has a good idea on where I can start verifying for my syslogd system? I have really 0 experience with syslogd and maybe I could be missing something obvious. I'd maybe use something like rsyslog and force TCP to verify that the messages made it to their endpoints, and if all the messages make it to the rsyslogd daemon use tcpdump/wireshark to figure out if the UDP datagrams (default transport layer for syslog) aren't getting dropped on the floor. Cheers! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: freebsd.org git repositories and svn ids
On Sat, Sep 1, 2012 at 4:28 PM, Daniel Hagerty h...@linnaean.org wrote: I use git://gitorious.org/freebsd/freebsd.git which has stable/releng/release branches and which does include git-svn-id This is what I'm using now, in fact. It lacks the 9.1 releng branch tho; I don't know if this is a bug or feature. More generally tho, I'm curious how one is supposed to use the seemingly more official repositories without this bit of data; I'd expect I must be missing some critical clue. The last time I looked (which was a while ago), the gitorious (and github? don't remember) repos were seriously out of date. Is the git.freebsd.org repo more or less up-to-date, or is it out of synch? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: GPT boot from 2nd. disk fails
On Wed, Aug 15, 2012 at 1:27 AM, Daniel Braniss da...@cs.huji.ac.il wrote: hi, this host has to disks: sa0 gpart show = 34 976773101 ada0 GPT (465G) 34128 1 freebsd-boot (64k) 1624194304 2 freebsd-ufs (2.0G) 4194466 33554432 3 freebsd-swap (16G) 37748898 939024237 4 freebsd-zfs (447G) = 34 976773101 ada1 GPT (465G) 34128 1 freebsd-boot (64k) 1624194304 2 freebsd-ufs [bootme] (2.0G) 41944668388608 3 freebsd-swap (4.0G) 12583074 964190061 4 freebsd-zfs (459G) but no amount of magic will cause boot from the second disk, it will always boot from the first disk. any insights? Use boot0cfg -s 5 (untested with GPT disks)? HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [maybe spam] Re: FreeBSD 1.x Binaries Work Except under Chroot
On Wed, Aug 15, 2012 at 12:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 15 August 2012 11:54, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message CAJ-Vmo=yzcz_jdhtvq3kyhgxdnutvzqzpp+sdsz+zwe7cym...@mail.gmail.com , Adrian Chadd writes: Holy. Crap. 17 seconds? Can we please go back to having it take this long? please? 386BSD was even better, and I have a machine that boots it in less than 15 seconds from power-on... :-) Embedded systems stuff will love you if we could slim the build and binary/library size down by this much. Sheesh, compilers do a lot of work these days, don't they? Has anyone done a (recent) comparison of execution size/efficiency given the evolution of GCC? That and (obviously) the FreeBSD source tree has grown.. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Consistent use of lex flags
On Wed, Aug 8, 2012 at 1:59 PM, Dan McGregor danismostlik...@gmail.com wrote: Hi. I was just noticing that mkcsmapper doesn't build with clang. I saw two ways to do this, the first being to #define YY_NO_INPUT, and the other to use the %option noinput lex flag. While there, I decided to explore and I changed a bunch of #defines to the standard lex way of doing things. I thought it would be good if all the code that originated in FreeBSD could be consistent. Thoughts? Probably should CC gabor@ next time (done this time) and maybe involve the NetBSD folks as this code is sort of upstreamed from them IIRC. Cheers! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 2, 2012, at 9:20 AM, Scott Long wrote: On Aug 2, 2012, at 12:23 AM, Kevin Oberman kob6...@gmail.com wrote: Doug makes some good points. No, he doesn't. He and Arnould being argumentative and accusatory where none of that is warranted. I used to run the devsummits, and we did tele-conference lines for remote people to participate. After I stepped down, others took it up and did the same thing. Usually, the lines were unused. I suspect that organizers simply stopped thinking about them after a while because of poor interest. There is no conspiracy of exclusion here, just simple human apathy. The Watson/Losh connection worked really well in BSDCan 2010 :). Advertising the teleconferencing lines might be an issue (I would have loved to have joined in some of the remote conferences, if for nothing more than be a fly on the wall, this year), but that's a separate thing aside. There's some misunderstanding, assumption, etc mixed together in this mailing chain that I think is probably better resolved with some face-to-face conversations or maybe just more rational (and less heated) discussion. Thanks! -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to diagnose system freezes?
On Tue, Jul 31, 2012 at 5:02 PM, Yuri y...@rawbw.com wrote: One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it would usually cycle with a very short period. And system stops being sensitive to keyboard/mouse. Also ping of this system doesn't get a response. I would normally think that this is the faulty memory. But memory was recently replaced and tested with memtest+ for hours both before and after freezes and it passes all tests. One out of the ordinary thing that is running on this system is nvidia driver. But the freezes happen even when there is no graphics activity. Another out of the ordinary thing is that the kernel is built for DTrace. But DTrace was never used in the sessions that had a freeze. What is the way to diagnose this problem? As an aside, where do you see things lockup (Xorg, Firefox, etc)? Can you remain sshed into the box or not? What sound driver are you using and how are you playing sound/video? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pre-make and Post-make scripts
On Wed, Jul 25, 2012 at 5:49 AM, Brandon Falk bfalk_...@brandonfa.lk wrote: I'm curious as to how the best way of having a script run before and after make would be done. Would this require modification of the FreeBSD make template, or is this functionality already built in? The goal of this is to set up a script that prior to a build sends up a filesystem in ram (tmpfs) for the build to occur in, and afterwards saves the filesystem from ram onto the actual disk for backup/archiving. We all know that our poor disks could use a little break from the strain of build processes. Or just mount MAKEOBJDIRPREFIX (defaults to /usr/obj) in a swap backed disk / tmpfs? Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel: abra-kadabra
On Tue, Jul 10, 2012 at 7:36 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: On Tue, 10 Jul 2012, Damien Fleuriot wrote: On 10 Jul 2012, at 12:10, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: this is what i've got from kernel (same visible after dmesg of course) Jul 9 08:56:53 ... kernel: 66pipd6id p336i65d0 43432 ((hh6ttt6p2d4 )(t,p dht)t,pu di)du,i ud1i 0d14 80:10 e44x88i::t eex die txoiedtn eo dn sosini ggnsnaalilg n1a1l Jul 9 08:56:53 .. kernel: 1 Jul 9 08:56:53 ... kernel: Jul 9 08:56:53 ... kernel: 6611 Jul 9 08:56:53 ... kernel: 1 Jul 9 08:56:53 ... kernel: everything before and after seems usual. when reading every second letter it SEEMS to make more sense but still not much. What it is? You're seeing several messages at jumbled together, or your message and other parts of the buffer. Either way, you can see the word signal there ;) i think it was httpd (probably PHP trash) crashed with sig11 but want to be sure. httpd rarely do crash... Strange i have ports rather up to date and no KNOWN vulnerabilities are according to portaudit output. how can i prevent mixing kernel messages? i have options PRINTF_BUFR_SIZE=256# Prevent printf output being interspersed. in kernel config Increasing that value [to 1k, 2k, etc] will help at the cost of some more memory usage, but it won't fix the problem. The issue should be less prominent in 9.x+. HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, Jul 5, 2012 at 2:48 AM, Olivier Smedts oliv...@gid0.org wrote: 2012/7/5 Mike Meyer m...@mired.org: My objection was not due to misunderstanding about auto-install. I find the feature annoying - spewing a bunch of crap at me because of a typo. It annoys me far more often than it actually helps me, because more often than not the missing command is a typo, *not* an attempt to run a command I don't have. I.e., if I type mmap instead of nmap, I get: mwm@IPGhosterCrawlerI:~$ mmap No command 'mmap' found, did you mean: Command 'jmap' from package 'openjdk-6-jdk' (main) Command 'jmap' from package 'openjdk-7-jdk' (universe) Command 'gmap' from package 'gmap' (multiverse) Command 'gmap' from package 'scotch' (universe) Command 'tmap' from package 'emboss' (universe) Command 'smap' from package 'slurm-llnl' (universe) Command 'pmap' from package 'procps' (main) Command 'moap' from package 'moap' (universe) Command 'umap' from package 'libunicode-map8-perl' (main) Command 'map' from package 'sgt-puzzles' (universe) Command 'amap' from package 'amap-align' (universe) mmap: command not found And it really annoys me too because usually, instead of an immediate command not found, you've got a reply seconds later if on a not so fast computer. When working on Ubuntu, after a typo or missing command I have the time to realize that something strange is happening, to read again what I typed and to hit ^C before any message is displayed. Almost like you need a Better diagnostic message to note that a package database is being searched ;]... -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Better error messages for command not found (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, Jul 5, 2012 at 7:36 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: mwm@IPGhosterCrawlerI:~$ mmap No command 'mmap' found, did you mean: Command 'jmap' from package 'openjdk-6-jdk' (main) Command 'jmap' from package 'openjdk-7-jdk' (universe) Command 'gmap' from package 'gmap' (multiverse) Command 'gmap' from package 'scotch' (universe) Command 'tmap' from package 'emboss' (universe) Command 'smap' from package 'slurm-llnl' (universe) Command 'pmap' from package 'procps' (main) Command 'moap' from package 'moap' (universe) Command 'umap' from package 'libunicode-map8-perl' (main) Command 'map' from package 'sgt-puzzles' (universe) Command 'amap' from package 'amap-align' (universe) mmap: command not found are you serious that linux distros have such a think now? I didn't use linux for a long time and no plan to use it, but you are joking isn't it? It's a Debian thing. It doesn't exist [out of the box] on Gentoo, Redhat, Suse, etc. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, Jul 5, 2012 at 10:18 AM, Warner Losh i...@bsdimp.com wrote: On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. Here's a *random* thought to consider. This seems like a feature that FreeNAS/PC-BSD/etc (Linux/Windows/other OS convert) type thing might want -- so maybe the feature should exist (but be off) in FreeBSD and exist (and be on) in custom FreeBSD distros where users aren't necessarily expected to know FreeBSD. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, Jul 5, 2012 at 10:31 AM, Garrett Cooper yaneg...@gmail.com wrote: On Thu, Jul 5, 2012 at 10:18 AM, Warner Losh i...@bsdimp.com wrote: On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. Here's a *random* thought to consider. This seems like a feature that FreeNAS/PC-BSD/etc (Linux/Windows/other OS convert) type thing might want -- so maybe the feature should exist (but be off) in FreeBSD and exist (and be on) in custom FreeBSD distros where users aren't necessarily expected to know FreeBSD. And FWIW, this can exist as a *port* which is LD_PRELOADed (or use some other LD* hack) as an opt-in for a select set of shells. -Garrett PS I personally don't care about this feature on FreeBSD, but I understand how to use FreeBSD. I sometimes find it helpful on other OSes like Debian that I don't actively use all of the time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
On Thu, Jul 5, 2012 at 10:18 AM, Warner Losh i...@bsdimp.com wrote: On Jul 5, 2012, at 10:45 AM, Damien Fleuriot wrote: On 7/5/12 6:38 PM, Wojciech Puchar wrote: inexperienced users. Having to enable it manually defeats its very purpose. so is FreeBSD future direction to be moron-OS just like linux is now, or is that just another stupid idea on that forum that came and... will pass? Quite important. There are still people that want normal OS. Just because you don't like the idea doesn't make it stupid, and just because it comes from linux doesn't make it bad. Both true. However, if the database lookups took a long time, or had a high overhead to maintain, then it would be stupid to have on by default. One other thing: just because one can build ports on an ARM board or a Netbook, it probably isn't the best idea in the world to do (although I do it because I'm too lazy to setup a Tinderbox for all 5 of my FreeBSD hosts). Similarly, building a database of command to package mappings on an underspec'ed machine is probably not the wisest thing to do. Given that the data changes relatively infrequently, it seems like something that would be best generated along with packages. Or -- here's a novel thought! Figure out how Debian does it, steal the data produced with their packaging scheme, then remap the .debs to FreeBSD ports/packages! Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nvidia-driver-295.49 is highly unstable
On Jul 3, 2012, at 8:20 PM, Yuri y...@rawbw.com wrote: On 05/27/2012 13:08, Alexey Dokuchaev wrote: Perhaps you can try asking on official nVidia FreeBSD forum: http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 I reported there 05-28-12, but got no response. Do you know if there is a way to report a problem with NVidia? For example, is there a for example bugzilla or other bug reporting system for this? ... There isn't an official means to do this (maybe due to resource constraints), but word of warning: they ban people that nag too much about the right topics. Thanks, -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How does bootinfo64.c find read_eflags() and write_eflags() on amd64?
On Mon, Jul 2, 2012 at 2:40 AM, Richard Yao r...@gentoo.org wrote:
/usr/src/sys/boot/i386/libi386/bootinfo64.c uses read_eflags() and
write_eflags(), which live as inline functions in
/usr/src/sys/i386/include/cpufunc.h.
/usr/src/sys/boot/i386/libi386/bootinfo64.c also includes
/usr/include/machine/cpufunc.h, but that is
/usr/src/sys/amd64/include/cpufunc.h on amd64, which does not contain
either of them.
I do not understand how FreeBSD's build system finds these. I am trying
to build /usr/src/sys/boot on Gentoo Linux, but Gentoo Linux does not
understand this either:
# env CFLAGS=-march=core2 -mtune=core2 -O2 -pipe -O2
-fno-strict-aliasing -D__FreeBSD__=9 -D__FBSDID\(x\)= -nostdinc
-I/var/tmp/portage/sys-boot/boot0-9.0/work/include_proper
MACHINE_CPUARCH=amd64 MACHINE_ARCH=amd64
MAKESYSPATH=/usr/share/mk/freebsd pmake
Warning: Object directory not changed from original
/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader
cc -march=core2 -mtune=core2 -O2 -pipe -O2 -fno-strict-aliasing
-D__FreeBSD__=9 -D__FBSDID\(x\)= -nostdinc
-I/var/tmp/portage/sys-boot/boot0-9.0/work/include_proper
-DLOADER_NFS_SUPPORT -DBOOT_FORTH
-I/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/../../ficl
-I/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/../../ficl/i386
-DLOADER_GZIP_SUPPORT -DLOADER_GPT_SUPPORT
-I/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/../../common
-I. -Wall
-I/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/..
-I/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/../btx/lib
-ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow
-mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99
-static -Wl,-Ttext,0x0 -nostdlib -Wl,-m,elf_i386 -o loader.sym
/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/../btx/lib/crt0.o
main.o conf.o vers.o boot.o commands.o console.o devopen.o disk.o
interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o
load_elf32.o load_elf32_obj.o reloc_elf32.o load_elf64.o
load_elf64_obj.o reloc_elf64.o bcache.o isapnp.o pnp.o interp_forth.o
/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/../../ficl/libficl.a
/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/../libi386/libi386.a
/usr/lib/libstand.a
/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader/../libi386/libi386.a(bootinfo64.o):
In function `bi_load64':
bootinfo64.c:(.text+0x45a): undefined reference to `read_eflags'
bootinfo64.c:(.text+0x469): undefined reference to `write_eflags'
bootinfo64.c:(.text+0x46e): undefined reference to `read_eflags'
collect2: ld returned 1 exit status
*** Error code 1
Stop.
pmake: stopped in
/var/tmp/portage/sys-boot/boot0-9.0/work/sys/boot/i386/loader
How does bootinfo64.c obtain these symbols on FreeBSD?
Via patterns like the following sprinkled around Makefiles under
sys/boot that link things to their proper spots:
ln -sf ${.CURDIR}/../../../${MACHINE_CPUARCH}/include machine
Cheers,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: sysctl filesystem ?
On Mon, Jun 25, 2012 at 5:03 PM, Arnaud Lacombe lacom...@gmail.com wrote:
Hi folks,
I find myself in a situation where I need to directly explore the
sysctl(8) tree from my program. The tricky part is this:
from `src/sbin/sysctl.c':
/*
* These functions uses a presently undocumented interface to the kernel
* to walk the tree and get the type so it can print the value.
* This interface is under work and consideration, and should probably
* be killed with a big axe by the first person who can find the time.
* (be aware though, that the proper interface isn't as obvious as it
* may seem, there are various conflicting requirements.
*/
AFAIT, the whole interface used by sysctl(8) to explore the sysctl
tree (ie. list, name, get description) is undocumented. This comment
has been there for about, well... 17 years. No matter to say that it
is highly unlikely anyone is ever gonna design that perfect interface.
Right now, I am left with no choice but to figure out how that stuff
work, which I foresee will be a real PITA. No choice ? Well, not so
much. About 12 years ago a filesystem interface was written for
sysctl, namely scfs(4). It was authored by Kelly Yancey and (?) Boris
Popov. Unfortunately, time passed and no code is any longer publicly
available. URLs are either no longer valid or password-protected.
This interface would just be perfect for my use-case. No need to spend
time decoding a prehistoric interface, no need to craft custom
accessors. I would just have to use standard POSIX file interface...
if the code was available.
I was hoping some of the people on this list would either, have the
scfs(4) code on their drives/tapes, or have a way to contact the
original author(s) and thus have a chance to get that code ?
Thanks in advance,
- Arnaud
ps: I know the code will certainly have to be fixed, but that is still
the best option I've got so far.
Alternatively, the interface could just be documented (from
sys/kern/kern_sysctl.c):
/*
* Staff-functions
*
* These functions implement a presently undocumented interface
* used by the sysctl program to walk the tree, and get the type
* so it can print the value.
* This interface is under work and consideration, and should probably
* be killed with a big axe by the first person who can find the time.
* (be aware though, that the proper interface isn't as obvious as it
* may seem, there are various conflicting requirements.
*
* {0,0}printf the entire MIB-tree.
* {0,1,...}return the name of the ... OID.
* {0,2,...}return the next OID.
* {0,3}return the OID of the name in new
* {0,4,...}return the kind format info for the ... OID.
* {0,5,...}return the description the ... OID.
*/
I know 2 closed-source versions that have wholesale stolen/borrowed
the code from sysctl(3), and I adapted the sysctl(8) code for my own
uses for the cython derivative I made here [1].
Thanks,
-Garrett
1. http://sourceforge.net/projects/sysctl/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: libgeom documentation?
On Mon, Jun 25, 2012 at 4:56 PM, Dave Hayes d...@jetcafe.org wrote: Libgeom has these functions geom_gettree() and geom_getxml but there is no documentation in the man page. Was this intentional? Is there a place these functions are documented other than their source code? :) I can't really say 100%, but I found some documentation about it here: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/geom-class/article.html . It was probably discussed in a previous BSDCan as well. You can access this via sysctl -b kern.geom.confxml, but the problem that I see based on the above article is that the printout content and format is GEOM-class topology dependent. Cheers, -Garrett PS freebsd-geom might be a better list.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Jun 20, 2012, at 12:45 AM, Doug Barton wrote: I was working on a reply along similar lines, but instead I'll say that i agree 100% with what Mark said, and thanks to him for saving me a lot of time. :) Richard, with all that said if you still are interested in specs for a test program, I'm still willing to help with that. Just let me know. I agree with both Mark and Doug. For the record, my point wasn't to discourage anyone from proposing ideas or to do good work. If the change is beneficial and helps make folks' lives easier, I'm sure at least one person will welcome the change with open arms in FreeBSD proper. Thanks, -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Mon, Jun 18, 2012 at 10:04 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:39 AM, Wojciech Puchar wrote: - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. OpenRC init scripts lack such delays. They store dependency information, which enables OpenRC to start them as soon as their dependencies are ready. Assuming that the hacks aren't working around other issues, like routes not already being available for a certain period of time, e.g. defaultroute, etc (which doesn't work 100% of the time, e.g. static gateways and mounting NFS shares). This is something that launchd, systemd, upstart, etc handle (because they either have more knowledge of the system or it's been coded into the files that execute the jobs/services), or alternatively the services need to fail more gracefully (this is more difficult -- but not impossible -- to code). Even OpenRC in gentoo doesn't handle this, unless things have changed dramatically since I used Gentoo ~2 years ago... Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. I don't say they are not needed but that they exist. anyway i don't understand sleep 1 after setting default route. Probably working around annoying races in the driver / network / routing stack. Please see my previous reply. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 04:12 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Would you elaborate on what you consider to be acceptable? Honestly, I am not certain if you will appreciate any tests unless you do them yourself. Change /etc/rc to use OpenRC in the base system. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 3:45 PM, Richard Yao r...@funtoo.org wrote: On 06/19/2012 06:17 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 04:12 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Would you elaborate on what you consider to be acceptable? Honestly, I am not certain if you will appreciate any tests unless you do them yourself. Change /etc/rc to use OpenRC in the base system. -Garrett That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate OpenRC into FreeBSD would be an inefficient use of my time. Not only would I fail to gain any improvements on my systems, but I would divert development time from things that do benefit me. People can use Gentoo FreeBSD in jails (or on physical hardware) to do comparisons. If they like it, Gentoo's developers are willing to help, but you cannot expect us to do your work for you. That would be like asking the Clang developers to replace your system compiler or the Illumos developers to replace your file system. FreeBSD's developers need to be the ones to import OpenRC into FreeBSD's base system, not us. We will just fix problems you encounter and collaborate on improvements. That is what every other upstream does. No. I'm saying that this is what would need to be done to qualify it and it would need to be run with the base system and a series of rc scripts in ports. In order for things to ultimately be committed, things would need to be regression tested enough that FreeBSD developers would be confident with the end-result. And yes, there would need to be a conversion plan, documentation update, and the full nine yards for whatever's done with an rc replacement, as this would impact a lot of folks and projects. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: BIO_DELETE equivalent for file on FFS filesystem
On Sat, Jun 16, 2012 at 1:34 PM, Mike Meyer m...@mired.org wrote: On Sat, 16 Jun 2012 21:04:26 +0100 Chris Rees utis...@gmail.com wrote: On Jun 16, 2012 8:37 PM, Xin LI delp...@gmail.com wrote: On Sat, Jun 16, 2012 at 12:01 PM, Chris Rees utis...@gmail.com wrote: On Jun 14, 2012 5:49 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: file to take 900MB or... can i call some system function to punch holes? I think you can only truncate the file at this time, pretty much like brk() works for memory. BAD. suppose i keep windoze VM image on filesystem which takes 10GB but uses 5GB. i could write simple program to find out what blocks are unused and then...do nothing. What if you cp it? That would be a dd(1) unless we teach cp(1) how to do sparse. I think what he wanted is to tell the OS I don't need block XX - YY anymore and the OS creates a sparse hole, which is not available at this time. Sorry, I must have misread. I take it cp would take a file with holes and only copy the data part? i.e. take a 10G file of which 5G is a hole, you'd end up with a 5G file? No, cp just does read()s. Reading data from a hole returns a block full of zeros. A quick test (after writing a program to create the file) shows this: bhuda% df -h . Filesystem Size Used Avail Capacity Mounted on /dev/md0 123M 1.2M 112M 1% /tmp bhuda% ls -lh holey.test -rwxr-xr-x 1 mwm wheel 953M Jun 16 16:22 holey.test Ok, I've got a file that's 953M on an FS with 1.2 meg used. It's got holes. bhuda% cp holey.test foobar /tmp: write failed, filesystem is full cp: foobar: No space left on device And doing a cp fails. Use dd conv=sparse to get the effect you want. Our version of cp doesn't support sparsing of files, but Linux's does: http://linux.about.com/od/commands/l/blcmdl1_cp.htm Our copy of dd and rsync are the two common tools I know of that properly handle sparse files if the underlying filesystem supports it (like Xin said), apart from writing a tool to do the necessary calls to lseek to do the right thing in the file (which is possible, but you would need to potentially read the whole file in, or pieces, similar to defrag until Windows might do). Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Fri, Jun 15, 2012 at 1:18 AM, Adrian Chadd adr...@freebsd.org wrote: 10.x will likely be more stable if 9.x gets stressed, and the bugs from there get fixed in -HEAD. I know this goes against what users expect, but as a software developer, QA is only as good as your testing and validation procedures. :) Being a realist (once again) most groups I've dealt with that have the resources to test their releases lag behind by CURRENT-2 major releases to avoid pushing unqualified code out on to customers. Not everyone is willing to bet on the bleeding edge of things, but this needs to change in order for things to move forward (this is something that my previous mentor at IronPort -- ambrisko@ -- encouraged for me to do and he exercised on a regular basis). The problem is time when it comes to pushing features forward to a newer OS release and testing them (IronPort used to do this, but no longer does as the individuals who used to do this left the group for other greener pastures). Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Solving the great resource problem, take 42 (Re: Upcoming release schedule - 8.4 ?)
On Wed, Jun 13, 2012 at 10:25 PM, Royce Williams royce.willi...@gmail.com wrote: On Wed, Jun 13, 2012 at 8:30 PM, Adrian Chadd adr...@freebsd.org wrote: On 13 June 2012 21:26, Mark Linimon lini...@lonesome.com wrote: On Wed, Jun 13, 2012 at 08:50:24AM -0700, Garrett Cooper wrote: The only way that this would really work is if there were dedicated sustaining engineers working on actively backporting code, testing it, committing it, etc. I'm going to agree with Garrett here. IMHO we've reached (or surpassed) the limit of what is reasonable to ask volunteers to commit their spare time to. This is doubly true when we have more than one stable branch. I totally concur. Ah, but you can get the same effect by freeing up those engineers to work on the hard stuff. This is my usual soapbox (see [1], [2]): Push more of the mundane work out to the edges, so that the developers can focus more on the core (like more releases/features/testing/projects). Here are some ideas. Only developers can implement them, but they would start paying for themselves immediately ... in developer time. - Frequent snapshots, with tools to automatically apply them and roll them back (freebsd-update + ZFS snapshots?). - Tools to do binary walks of snapshots to pinpoint when a bug appeared. (Think 'git bisect' + freebsd-update.) - A taggable FAQ that supports faceted search, and a quick way to add entries (or propose them for approval). - A way to search for known fixes to transient bugs and hardware issues [1]. - General debugging and testing tools for non-developers, including tools for filing smarter bug reports. - A way to automatically upload crash dumps for bulk analysis (like Windows does). - A dmesg analyzer that downloads a list during install, and looks for known issues (or workarounds) with your hardware for that version of FreeBSD (or recommend a different version!). Tools like these would also help more people achieve the I tried it, and it Just Worked moment. This can keep people's interest long enough to give FreeBSD a serious try. Some of them might enter the volunteer pool. I'm not a developer, but if some of the above could be tackled, they might free up enough Developer Equivalents (DEs, a term which I have just made up) to be more than worth the effort. No offense, but speaking from experience, these are referred to as wishlist projects -- many of which get shelved until developers get enough time to work on them. This makes more sense when there are more resources so engineers can work in a less distracted manner as BSD is not Linux as far as BSD's design stratagem is concerned . This is really starting to get philosophical and away from the original intent behind the original post, but given past discussions and the fact that these topics end up going around in circles/cycling through periodically (I've seen it on ports, current/stable/hackers, etc), here's my perspective after having read these discussions a few times and given what I've seen with the project over the last 5-10 years (granted, I've become a jaded realistic/pessimist in past years, so YMMV): Problem Statement (or the I want to have my cake and eat it too Issue): - Users want stability, but want latest and greatest driver code and features. These are [generally] mutually exclusive. Impedance: - There aren't enough volunteer resources to do what consumers of FreeBSD want beyond what's being done, with exception of developers and other volunteers going above and beyond in extraordinary circumstances to get the job done, or doing something his/her day job requires. The former case tends to be more of the exception than the norm. The latter happens sporadically. - There are plenty of companies out there wanting to solve this problem of release cycles, but no one group (or groups) is standing up and actively ponying up dedicated resources on a regular basis to make this a reality. What happens: Trivial tasks, like MFCing, testing, triaging, etc are being done by lead developers in a particular domain, which steals cycles from enhancement/bugfixing work in those areas [or other surrounding areas]; instead of investing time writing regression tests so others can do the work, no one other than the lead developers in a given area can do the work if it requires domain knowledge and/or specific hardware resources to complete the task. Eventually something happens, the developer becomes less active in the community (gets a family, no longer does FreeBSD work, gets a job, number of different things), and depending on the bus factor the particular area being maintained may remain unmaintained for some time. Alternatively, contact is done infrequently enough that interested parties willing to contribute code get discouraged and go off and do their own thing (be it support their own custom distro, switch to another OS, etc). In the former case, there's duplication of effort, some (or most) of which
Re: Import crt{begin,end}.S from NetBSD
On Thu, Jun 14, 2012 at 7:39 PM, Richard Yao r...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/14/12 22:24, Alexander Kabaev wrote:
On Thu, 14 Jun 2012 22:00:18 -0400 Richard Yao r...@gentoo.org
wrote:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
On 06/14/12 20:51, Alexander Kabaev wrote:
On Thu, 14 Jun 2012 14:54:28 -0400 Richard Yao
r...@gentoo.org wrote:
NetBSD has replacements for GCC's crt{begin,end}.S:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/arch/?only_with_tag=MAIN
This would complement compiler-rt and libstdc++. We intend to
import it in downstream Gentoo FreeBSD.
Could this be imported into FreeBSD-CURRENT?
Apart from licensing, what others reasons are there to do
that?
These components should not be tied to a specific compiler. If
GCC is going to be deprecated, then they should be replaced.
Anyway, having this tied to GCC has caused headaches for Clang
integration in Gentoo. In particular, we let the user pick the
toolchain that he uses, so we cannot place GCC's crt{begin,end}.o
in the same location that FreeBSD uses. This makes it difficult
for Clang to find the correct crt{begin,end}.o. We will likely
import the NetBSD crt{begin,end}.S code to rectify this, but it
would be preferable to do this in upstreamFreeBSD.
Assuming NetBSD version is a direct plugin for crtbegin/end
provided by GCC, I see no reason why we cannot do that. Are you are
willing to do the work and submit the patch, or would like to wait
for someone on our side?
Gentoo FreeBSD is currently based on FreeBSD 9-RELEASE. I plan to do
the work to import this downstream within the week, but I am not
running CURRENT. It might be necessary to iterate on the patches
before they can be merged. When I have them, should I file a PR or
post them to the list?
File a PR, post a link to the PR on a list / to devs generally is
the best way to go.
Thanks!
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Wed, Jun 13, 2012 at 5:53 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday, June 12, 2012 8:01:00 pm Adrian Chadd wrote:
hi,
You don't need to change the FreeBSD culture. We'd love to do an 8.4
release. And an 8.5 release, and 8.6 release, etc. The problem is one
of resources and time, not of culture/desire.
I disagree. The pace of X.0 releases is a deliberate choice FreeBSD
has made and directly impacts the number of live branches in existence.
Given our developer base, we can't really support 3 branches concurrently
(head + 2 stable like we have now with head, 9, and 8). Having longer lived
stable branches requires either increasing resources to support exising
releases longer, or slowing the pace of X.0 releases (but more aggressively
merging things from HEAD back). The latter case, especially, is part of
the culture and would be a choice we as a Project would have to make.
The only way that this would really work is if there were
dedicated sustaining engineers working on actively backporting code,
testing it, committing it, etc as the current paradigm requires the
developer (or another stand-in developer in the event that the
original developer failed to MFC the code) to do the work (which is
sort of what the OP is doing in this case, and what I've seen a few
different groups do that don't run bleeding edge code). That concept
doesn't really exist today. Maybe this would be a good idea for
improving the longevity of release cycles and maybe that's what
ultimately needs to be done as it would reduce distractions on
developers actively churning away on {[CURRENT-1],}[CURRENT], and
maybe that's what should be proposed.
As good as BSDi was from what I hear, that business model alone
won't probably work as many people take the support piece (companies
that just want the software and might develop/support apps/services on
top of it) and the longevity piece (companies that develop with/on the
software as a product) separately. They're typically (but not always)
mutually exclusive from what I've seen in my limited experience.
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD Boot Times
On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falk bfalk_...@brandonfa.lk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. The single process nature of rc is a big part of the problem, as is the single AP bootup of FreeBSD right before multiuser mode. There are a number of threads that discuss this (look for parallel rc bootup or something like that in the current, hacker, and rc archives -- the most recent discussion was probably 6~9 months ago). Given past experience, a big part of getting past the parallelized rc mess would be to make services fail/wait gracefully for all their resources to come up before proceeding. It's not easy, but it's possible with enough resources. HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ifconfig accepting hostname as ipv4 address
On Sat, Jun 9, 2012 at 12:23 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: input. Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you can't set valid CIDR address using this notation. Classful era has ended more than 10 years ago, do we still want to keep this behavior? were not aware of that option, and it is rather stupid option - you should work on addresses not names when configuring network I agree that it's not the best configuration in the world, as it would only work 100% if a machine had proper DNS records or a definitive hosts file. There are already enough bugs with static IP configurations and hostnames as-is *I'm looking at you mountlate* -- no sense to introduce more potentially buggy interoperability that only works in a handful of niche cases. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: boot menu option to disable graphics mode
On Thu, Jun 7, 2012 at 7:29 AM, Doug Barton do...@freebsd.org wrote: On 06/07/2012 02:57 AM, Gleb Kurtsou wrote: What do you think about adding generic support for overriding *_enable options in rc.conf? I'd like to be able to disable services at boot prompt, e.g. # set rc.slim_enable=no -- overrides slim_enable=yes in rc.conf Similarly rc.pf_enable=no Then introduce x_enable knob (=yes by default) to disable login managers. User will be able to override this setting with # service xdm forcestart Why not just: boot single user fsck -p mount -a $EDITOR /etc/rc.conf[.local] I've run into _multiple_ scenarios where this isn't possible because the terminal settings are screwed up in single user mode, and had to resort to `sed -i '' `. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: boot menu option to disable graphics mode
On Thu, Jun 7, 2012 at 2:57 AM, Gleb Kurtsou gleb.kurt...@gmail.com wrote: On (07/06/2012 11:56), Andriy Gapon wrote: on 07/06/2012 11:47 Konstantin Belousov said the following: On Thu, Jun 07, 2012 at 10:45:26AM +0300, Andriy Gapon wrote: It's long been a wish of mine to have an ability to decide at boot time that a system should boot in console-only mode. That is, that no graphics/X applications like e.g. xdm/kdm/gdm are automatically started even when they are configured to do so. Here is my attempt at implementing that: https://gitorious.org/~avg/freebsd/avgbsd/commit/96f7051d63d4286ef6f0196d241e7855338a6ed7?format=patch All the option does at boot time is setting of 'inhibit_gui' variable for kernel environment. I envision that this variable could be properly and gracefully handled in various startup scripts and/or application startup logic. But to ensure that the option is always honored I've also added ultimate protection to syscons that prohibits KDSETMODE/KD_GRAPHICS ioctl. This is too much, IMO. I understand why you may want to disable auto-start of login manager, but preventing a user from running X at all until she learns about kenv -u _and_ obscure code somewhere in the kernel, is unreasonable. A user doesn't have to select the option unless he needs to. A simple user can just reboot without selecting the option to get back his X. A user doesn't have to learn anything about the code, just about kenv and magic inhibit_gui variable. What do you think about adding generic support for overriding *_enable options in rc.conf? I'd like to be able to disable services at boot prompt, e.g. # set rc.slim_enable=no -- overrides slim_enable=yes in rc.conf Similarly rc.pf_enable=no Then introduce x_enable knob (=yes by default) to disable login managers. User will be able to override this setting with # service xdm forcestart It needs to be profiled, but I would be curious what the slowdown would be for this change. Also, it sort of introduces a fun chicken and egg problem with sourcing rc.conf files, like I discovered recently at $JOB. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gnome start error?help me.
On Sun, May 13, 2012 at 5:09 AM, cz li willing...@gmail.com wrote: I installed FreeBSD9.0 to IBM R51.Gnome startup black screen, only to restart.My graphics card is 82852/855GM Integrated Graphics Device.Is there any solution?Can you give me a detailed step？ Thank you! That card isn't fully supported on FreeBSD yet (it's GEM based), but you can use one of the other drivers (like vesa, etc) in the meantime and hold tight for when GEM support will be available in FreeBSD. Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Thoughts about kenv emulating sysctl
Hi Hackers, I've been asked to write up a script to analyze tunables via kenv for archival purposes an to establish a baseline set of static variables. In order to make life easier (and be able to do all the grunt work in a shell one-liner instead of introducing a bug prone tunable parser) I have written up a patch which would make kenv function a bit more like sysctl, wrt the fact that sysctl -n suppresses suffixing a value with the variable name when executed like so: # kenv LINES LINES=24 # kenv -n LINES 24 I've also considered keeping the functional defaults and instead do the following... # kenv -v LINES LINES=24 # kenv LINES 24 Pro of the first form is that it matches sysctl, pro of the second form is that it doesn't break backwards 'compatibility'. I know kenv isn't a widely used utility (albeit, I have seen it used in a few spots outside of FreeBSD proper), but I was wondering if anyone could see any potential pitfalls or would have a large degree of heartburn over changing the default to match sysctl. Thanks! -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Thoughts about kenv emulating sysctl
Hi Aleksandr! On Wed, May 9, 2012 at 3:02 PM, Aleksandr Rybalko r...@ddteam.net wrote: On Wed, 9 May 2012 09:05:47 -0700 Garrett Cooper yaneg...@gmail.com wrote: ... Hi Garret, I use it for embedded, kenv is good transport shared by loader, kernel and userland (since there is no RW storages). Indeed. IMO, kenv != sysctl, so we not need to match sysctl. But backwards 'compatibility' is good reason to select second way. Which is what I figured; I favored the latter course at first and developed my patch based on that mindset, because I know people hate it when backwards compatibility is broken :) (in all fairness I'm generally one of them). Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ways to promote FreeBSD?
On Apr 30, 2012, at 10:09 PM, Wojciech Puchar wrote: Advertising that it exists and is used is more important than saying x sucks, use y instead. This is the tone I was getting from the previous response and this is what I discourage as well as others on the list. It was just an example. I don't use FreeBSD because Oracle Solaris sucks but because it works best for me. No other unix not only is as fast but allows so easy tuning like compiling own kernel and configuring things. What do you prefer - few files in /etc, like rc.conf to configure almost everything in base system (+starting installed ports), or thousands of files in modern linux distro or oracle solaris? Sorry but when i HAD to deal with linux i just deleted most of /etc and write my own /etc/rc. Joe user, students, etc really don't care about the underlying system as long as the GUIs obscure this. OSX is a prime example of this (the OSX CLI has sucked for a long time). Only sysadmin and CLI power users care how things like this are organized. I think this is the usability boat that's been missed for a while on *nix. Solaris 11 was just an example of overadvertised things that are just useless. Linux is trendy and quality is second thing, but it had to be everywhere including things that should not have OS at all, like VoIP gateway. Sun isn't Oracle, so I don't expect them to put forth a decent general purpose OS offering. As far as Linux is concerned, in some ways it's good Linux has become a niche OS, and in some ways it's bad, but you can't take back the fact that it is what it is right now. Thanks, -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ways to promote FreeBSD?
On Apr 29, 2012, at 10:16 PM, Wojciech Puchar wrote: I prefer less advanced FreeBSD Ridiculing other projects is not a great way to show superiority. +1 Leave mudslinging to marketing and politicians :).. as for now you and few other people work hard to DE-promote FreeBSD from those few people that are able to make use of it but yet didn't. I'm sorry… I didn't realize that resorting to petty tactics to achieve one's goals was the way to do things. If it's better, the proof will be in the pudding and people will flock to it (as another old adage goes -- if you build it, they will come): plain and simple. Or more exact - delay, because those that need it sooner or later will start using it. Advertising that it exists and is used is more important than saying x sucks, use y instead. This is the tone I was getting from the previous response and this is what I discourage as well as others on the list. If you can do it in a non-confrontational way, I'd say do it. Otherwise, please don't force your opinion down others' throats. Thanks, -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ways to promote FreeBSD?
On Apr 29, 2012, at 8:47 AM, Chris Rees utis...@gmail.com wrote: On 29 Apr 2012 16:33, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: FreeBSD installation and boot style are very nice . Personally I dislike very much Ubuntu-like installs ( nothing is displayed about what is going on ) and I never use it ( in spite of I am installing each release of it ) . Another way to promote FreeBSD - show Solaris first. Yesterday just to look downloaded from oracle. Incredibly slow, no idea what's going on not only while installing but when trying to do anything and understand /etc/ hierarchy. incredible slow mess - this is the most advanced unix from Oracle. I prefer less advanced FreeBSD Ridiculing other projects is not a great way to show superiority. +1 Leave mudslinging to marketing and politicians :).. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: best possible GJOURNAL device?
On Thu, Apr 26, 2012 at 10:16 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: http://www.vikingmodular.com/products/arxcis/ddr3/ddr3.html or ZFS ZIL device for ZFS fans. anyone know exactly how it is visible and how it works? In general devices like these that I've dealt with in the past are presented as SATA or SAS devices, but some devices require additional drivers (take Ramdrives devices for instance). isn't BIOS clearing out memory on reboot? Depends on the BIOS, the settings set in the BIOS, etc. FreeBSD is but it can be patched easily. I wouldn't depend on volatile memory working in a non-volatile manner unless it's battery backed (which companies like Ramdrive, STEC, Viking, etc do) and in which case all you're doing (depending on how the device is designed) is delaying writes out to non-volatile (NAND/NOR flash) or another non-volatile medium (USB thumbdrive? etc... I vaguely remember seeing a vendor doing something clever like that...). How to get DRAM controller mapping i mean what DIMM is at what address? What is located where should be opaque if the designer designed it properly (otherwise a driver will need to be added to interface with the device if the vendor is trying to be clever or is not fully conforming to ATA/SCSI standards). Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: best possible GJOURNAL device?
On Thu, Apr 26, 2012 at 10:42 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: http://www.vikingmodular.com/products/arxcis/ddr3/ddr3.html In general devices like these that I've dealt with in the past are presented as SATA or SAS devices, but some devices require additional drivers (take Ramdrives devices for instance). this one - as described - is 100% regular DDR3 DIMM and plugged as normal memory. Depends on the BIOS, the settings set in the BIOS, etc. FreeBSD is but it can be patched easily. I wouldn't depend on volatile memory working in a non-volatile manner unless it's battery backed (which companies like Ramdrive, STEC, this is supercapacitor backed. after poweroff it have enough time to write all to SLC flash chip. How to get DRAM controller mapping i mean what DIMM is at what address? What is located where should be opaque if the designer designed it properly (otherwise a driver will need to be added to interface with the device if the vendor is trying to be clever or is not fully conforming to ATA/SCSI standards). please read attached link. it is NOT SATA/ATA/SAS/PCIe device. I just read the product tearout. It says that it depends purely on BIOS support, which may or may not exist for your motherboard (and there's an SSD that it uses to write out the data in the event that power fails). So I'm guessing that if it works with your motherboard, it will work regardless of the OS. How it's presented to the OS? ENOCLUE (ask Viking). Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Why make(1) doesn't support the internal macro $ ?
On Apr 21, 2012, at 8:18 PM, Yuri wrote: When I run 'make' on the following makefile, $@ gets printed but $ doesn't. Why? Yuri --- Makefile --- file-out: file-in @echo target= $@ src= $; touch $@ You want `$`... .IMPSRC is something else… Cheers, -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
