Re: patch(1) depends on RCS - should it?
On Mon, Oct 07, 2013 at 04:17:03PM -0400, Eitan Adler wrote: patch(1) explicitly tries to use RCS (and SCCS) in certain cases. At the SCCS behavior is part of (the SCCS option in ) POSIX 2008. So far I haven't seen any reason for messing with it. Joerg ___ 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: bsdgrep status
On Sat, Mar 23, 2013 at 10:54:17AM +0100, Dominic Fandrey wrote: I'm tempted to conclude that bsdgrep is ready for deployment. There are still some issues. Joerg ___ 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: clang - odd macro / conditional expansion behaviour?
On Mon, Mar 11, 2013 at 08:17:08PM -0700, Adrian Chadd wrote: I've hit this rather amusing clang behaviour: I think you are hitting a variant of http://llvm.org/bugs/show_bug.cgi?id=10030. Joerg ___ 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: UFS1 vs UFS2
On Sun, Dec 30, 2012 at 08:39:26PM +0100, Paul Schenkeveld wrote: On Sun, Dec 30, 2012 at 02:21:26PM +0100, Wojciech Puchar wrote: OpenBSD by default use UFS1 for partitions smaller than 1TB. FreeBSD use always UFS2. UFS2 uses double the amount of space for inodes. basic operation seems the same. Does it make sense to use UFS1 for small filesystem (on SSD) that would have few millions of files. It will take less space for inodes, but how about performance? UFS2 became necessary when disk got bigger and sizes and block pointers in metadata on UFS1 became too small to fully utilize the larger disks. There is also the possible concern of Extended Attributes. If you use them, you might be a lot more happy with UFS2. Joerg ___ 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 09:00:26PM +0100, Chris Rees wrote:
:U -- with bmake has non-optional arguments, so for example:
${VAR:U} - pmake behaviour
${VAR:Uval} - make behaviour.
Would that be acceptable? I can get a patch in if that's popular.
${VAR:U} is useful for bmake as well. For example, .if conditionals can
avoid explicit checks for defined and/or quoting that way.
Joerg
___
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: SMP Version of tar
On Mon, Oct 01, 2012 at 10:16:53PM -0700, Tim Kientzle wrote: * Implement within libarchive directly. This would benefit tar and a handful of other programs that use libarchive, but may not be worth the complexity. The complexity shouldn't actually be that bad. Basically, use a large internal buffer in the compression filter and make the queueing for distribution to threads an implementation detail. Alternatively, just provide a compatible implementation of libz's event interface. Joerg ___ 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: GAS ATT linkage issue
On Wed, Jul 04, 2012 at 04:32:02PM -0700, Colin Barnabas wrote: movl $ebx, 28(%edi) ^ this should be %ebx, $ means a literal (immediate) value Joerg ___ 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: Browsing over IPv6
On Mon, Jul 02, 2012 at 05:09:36PM +0200, Wojciech Puchar wrote: to GET / HTTP/1.1). So what's the most likely point of failure? ^^ you already answered your question :) check telnet ... 80 GET http://fullsitename/ HTTP/1.1 Full URL is only valid for proxies. What you want to do is: GET / HTTP/1.0 Host: fullsitename empty line Joerg ___ 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: memmem small optimalisation
On Thu, Feb 23, 2012 at 05:34:03PM -0800, Xin Li wrote: Did you benchmarked the change? Changes like this has to be done very carefully since it's possible that the extra time spent on addition and subtractions, when multiple by the length of the long string, may actually defeat the benefit of one less byte worth memory compare because the effect of CPU's data cache. More importantly, if the input was originally aligned, the additional byte is ~free. Joerg ___ 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: easy way to determine if a stream or fd is seekable
On Tue, Nov 15, 2011 at 08:24:50PM +, Alexander Best wrote: one of the things i'm missing is an easy way to determine, whether a stream or fd is seekable. i checked the dd(1) and hd(1) sources and those tools are performing so much stuff just to find out if this is the case, and they still are doing a very poor job. Isn't the primary issue that FreeBSD doesn't properly report errors for lseek(2)? I think you should start from that and not hack around the fallout... Joerg ___ 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: easy way to determine if a stream or fd is seekable
On Wed, Nov 16, 2011 at 01:14:28PM +, Alexander Best wrote: On Wed Nov 16 11, Joerg Sonnenberger wrote: On Tue, Nov 15, 2011 at 08:24:50PM +, Alexander Best wrote: one of the things i'm missing is an easy way to determine, whether a stream or fd is seekable. i checked the dd(1) and hd(1) sources and those tools are performing so much stuff just to find out if this is the case, and they still are doing a very poor job. Isn't the primary issue that FreeBSD doesn't properly report errors for lseek(2)? I think you should start from that and not hack around the fallout... what do you mean? lseek(2) returns -1, when the file descriptor is not seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...) and it always returned the correct result. If that were the case, you wouldn't need your flag to detect seek support. But e.g. some devices silently ignore seek requests without reporting errors. At least that is what I remember from the last time this has brought up. Joerg ___ 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: reducing compiler instances during buildkernel
On Mon, Nov 07, 2011 at 06:46:24PM +1100, Peter Jeremy wrote: On 2011-Nov-05 22:30:21 +, Alexander Best arun...@freebsd.org wrote: wouldn't it be possible to somehow spawn N gcc or clang instances (make -jN buildkernel) and then pipe the src to one of those N instances? just like with something like multics N processes were started and then people used the job control language to load binaries into those processes. This is likely to require very non-trivial changes to gcc or clang. The major issue is that the process needs to be in a known initial state before beginning a compile - and it's very unlikely that the compiler cleans itself up enough to return to that state. Actually, the real problem is that a full cleanup is likely to be as expensive as fork+exec. Joerg ___ 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: limits do not apply
On Mon, Nov 07, 2011 at 01:24:05PM +0900, rozhuk...@gmail.com wrote: Scripts for which the specified user inherit it from the startup script, rather than generate it based on the settings for the user. #su -m mysql -c '/bin/sh -c /usr/bin/env' Try to use su -c default -m mysql ... Joerg ___ 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: .eh_frame, .eh_frame_hdr - how to remove that trash
On Thu, Oct 20, 2011 at 09:41:24AM +0200, Wojciech Puchar wrote: how to do this and what the hell it is used at all? It is used to allow unwinding stack frames. That is required for exception handling with C++ and also to allow debugging in the presence of -fomit-frame-pointer, e.g. as used by default on AMD64. Joerg ___ 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: [LIBC] Modfied Version of sscanf
On Mon, May 02, 2011 at 02:13:11PM +0200, Martin Möller wrote: o strchr, memchr is too low-level and not elegant enough Actually, you are looking for strstr. Joerg ___ 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: Unsigned wchar_t
On Mon, Mar 28, 2011 at 08:36:57AM +1300, Andrew Turner wrote: Hello hackers@ I'm working on getting FreeBSD working with the ARM EABI. As part of this the Procedure Call Standard for the ARM Architecture (AAPCS) defines wchar_t as an unsigned int. Does someone at ARM actually get paid to define ABIs that are different from what everyone else is doing? Didn't we learn anything from the problems of char vs signed char vs unsigned char? Joerg ___ 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 ABI?
On Mon, Feb 21, 2011 at 03:16:55PM -0800, Yuri wrote: But I know for the fact that Solaris-i386 uses 16 byte alignment. At least that's what gcc-4.5.2 thinks when on Solaris. That's a major difference. The Linux people decided a while ago that stack alignment should be 16 Byte. GCC effectively forces that down everyone's throat because until at least GCC 4.2 or 4.3, it can't correctly realign the stack and just fails miserable. I would be surprised if it was a conscious decision for the Solaris either. The main exception here is Mac OSX, since it defined the x86 ABI a lot latter and doesn't claim to be SYSV compatible. Joerg ___ 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: man 3 getopt char * const argv[] - is const wrong ?
On Wed, Feb 16, 2011 at 07:41:02PM +0100, Matthias Andree wrote: But POSIX.1-2008 is the same as the Single Unix Specification v4 or IEEE Std 1003.1-2008. Minor correction, it is SUS v3 Issue 7. Joerg ___ 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: man 3 getopt char * const argv[] - is const wrong ?
On Wed, Feb 16, 2011 at 08:26:04PM +0100, Matthias Andree wrote: Am 16.02.2011 20:02, schrieb Joerg Sonnenberger: On Wed, Feb 16, 2011 at 07:41:02PM +0100, Matthias Andree wrote: But POSIX.1-2008 is the same as the Single Unix Specification v4 or IEEE Std 1003.1-2008. Minor correction, it is SUS v3 Issue 7. No it isn't. See http://www.unix.org/version4/ieee_std.html POSIX.1-2008 is simultaneously IEEE Std 1003.1™-2008 and The Open Group technical Standard Base Specifications, Issue 7. Let's agree on that :) http://pubs.opengroup.org/onlinepubs/9699919799/mindex.html Joerg ___ 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: rtld optimizations
On Thu, Jan 27, 2011 at 06:24:18PM -0500, Alexander Kabaev wrote: For starters, the number of libraries given binary is linked too is completely and utterly irrelevant :) The change NetBSD guys claims to revolutionize his application startup times only applies to programs that dlopen (read - load dynamically) libraries with long largely identical dependency chains and calls dlsym on them many, many thousand times. I do not think you will find any real app out there that fits this description close enough to actually demonstrate the effect of the change that is distinguishable from the statistical noise. Pressing ^C certainly not precise enough for that. (1) The program itself needs to have a large enough number of linked libraries. (2) The program needs to dlopen() modules. (3) The program needs to search for missing symbols often enough. From memory, the real world example that fulfilled all three cases was Evolution. (1) and (2) are pretty typical though. Joerg ___ 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: What does the FreeBSD/i386 ABI say about stack alignment?
On Thu, Jan 13, 2011 at 12:19:00PM -0500, Ryan Stone wrote: I've been trying to get an application compiled with gcc 4.5.1 running on FreeBSD 8.1, but it's been crashing during startup with a SIGBUS. It turns out that the problem is that gcc is issuing SSE instructions(in my case, a movdqa) that assume that the stack will be aligned to a 16-byte boundary. It seems that Linux/i386 guarantees this, and I worry that gcc has extended this assumption to all i386 architectures. I'm assuming that FreeBSD doesn't make any such promises based on the fact that I'm getting crashes. FreeBSD follows the original SYSV ABI. Linux at some point silently decided to redefine the ABI to fit their mindset. I think you want to use a combination of -mpreferred-stack-boundary=4 and -mincoming-stack-boundary=2. Joerg ___ 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: What does the FreeBSD/i386 ABI say about stack alignment?
On Fri, Jan 14, 2011 at 12:00:52AM +0200, Kostik Belousov wrote: On Thu, Jan 13, 2011 at 10:57:15PM +0100, Joerg Sonnenberger wrote: On Thu, Jan 13, 2011 at 12:19:00PM -0500, Ryan Stone wrote: I've been trying to get an application compiled with gcc 4.5.1 running on FreeBSD 8.1, but it's been crashing during startup with a SIGBUS. It turns out that the problem is that gcc is issuing SSE instructions(in my case, a movdqa) that assume that the stack will be aligned to a 16-byte boundary. It seems that Linux/i386 guarantees this, and I worry that gcc has extended this assumption to all i386 architectures. I'm assuming that FreeBSD doesn't make any such promises based on the fact that I'm getting crashes. FreeBSD follows the original SYSV ABI. Linux at some point silently decided to redefine the ABI to fit their mindset. I think you want to use a combination of -mpreferred-stack-boundary=4 and -mincoming-stack-boundary=2. I think gcc [*] requires 16-byte alignment. Also, it follows the policy of not changing the stack alignment through the calls. Well, yes. GCC decided to force the Linux ABI change down our throat. It's not an issue if you decide to rebuild all your libraries every week, but it is a major PITA if you deal with old binary-only releases. Joerg ___ 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: MONITOR/MWAIT question
On Sat, Dec 18, 2010 at 02:24:34PM -0800, Matthew Dillon wrote: Does anyone know if an IRET cancels/triggers a MONITOR event? AMD's Architecture Programmer's Manual explicitly contains: Events that cause an exit from the monitor event pending state include: ... - Any far control transfer that occurs between the MONITOR and the MWAIT. Joerg ___ 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: Deterministic builds, part 2
On Thu, Dec 02, 2010 at 11:08:09AM +0100, Erik Cederstrand wrote: I wonder if I could hack __FILE__ to be a path relative to src/. That would be a way to fix all the source file paths I see. I have a patch for that in NetBSD's gcc. Joerg ___ 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: Deterministic builds, part 2
On Thu, Dec 02, 2010 at 02:52:33PM +0100, Erik Cederstrand wrote: Hi Joerg, Den 02/12/2010 kl. 13.49 skrev Joerg Sonnenberger: On Thu, Dec 02, 2010 at 11:08:09AM +0100, Erik Cederstrand wrote: I wonder if I could hack __FILE__ to be a path relative to src/. That would be a way to fix all the source file paths I see. I have a patch for that in NetBSD's gcc. Fantastic! Would you mind pointing me to the patch? http://mail-index.netbsd.org/tech-userlevel/2009/10/30/msg002857.html Joerg ___ 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: Network socket concurrency (userland)
On Tue, Nov 16, 2010 at 03:37:59PM +0100, Ivan Voras wrote: Are there any standard-defined guarantees for TCP network sockets used by multiple threads to do IO on them? System calls are atomic relative to each other. They may be partially executed from the perspective of a remote system, e.g. due to segmentation, but one system call will finish before the next call of the same category is started. Specifically, will multiple write() or send() calls on the same socket execute serially (i.e. not interfere with each other) and blocking (until completion) even for large buffer sizes? What about read() / recv()? All write operations are serialised against each other, just like all read operations are serialised against. Joerg ___ 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: Network socket concurrency (userland)
On Tue, Nov 16, 2010 at 04:51:04PM +0100, Ivan Voras wrote: On 11/16/10 16:19, Joerg Sonnenberger wrote: On Tue, Nov 16, 2010 at 03:37:59PM +0100, Ivan Voras wrote: Are there any standard-defined guarantees for TCP network sockets used by multiple threads to do IO on them? System calls are atomic relative to each other. They may be partially executed from the perspective of a remote system, e.g. due to segmentation, but one system call will finish before the next call of the same category is started. It seems to me that with a multithreaded kernel and multithreaded userland that cannot really be guaranteed in general (and really should not be guaranteed for performance reasons), but maybe it's true for e.g. sockets if they are protected by a mutex or two within the kernel? Of course it can be guaranteed. There are a few tricky bits like writing to a file with O_APPEND, but for sockets it is essentially all about taking a mutex before changes the socket buffer. Specifically, will multiple write() or send() calls on the same socket execute serially (i.e. not interfere with each other) and blocking (until completion) even for large buffer sizes? What about read() / recv()? All write operations are serialised against each other, just like all read operations are serialised against. To what degree is such serialization standardized (by POSIX?)? It is written somewhere, I forget where and can't find it right now :) Joerg ___ 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: Timestamps in static libraries
On Tue, Oct 05, 2010 at 03:28:36PM +0200, Erik Cederstrand wrote: I'm wondering if this is necessary, or if this can possibly be turned of with a knob somewhere. Newer binutils got a flag after a discussion about this and related issues in NetBSD. It basically stores 0 for the uid/gid/time fields. Joerg ___ 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: ar(1) format_decimal failure is fatal?
On Sat, Sep 18, 2010 at 12:01:04AM -0400, Benjamin Kaduk wrote: GNU binutils has recently (well, March 2009) added a -D (deterministic) argument to ar(1) which sets the timestamp, uid, and gid to zero, and the mode to 644. That argument was added based on discussions on NetBSD about doing bit-identical release builds. It was made optional for the possible users of the data, not that we are really aware of anyone using it. The ar(1) support in make basically goes back to a time when replacing the content was a major speed up for incremental builds and it is pretty much useless nowadays. Similary the timestamp, it doesn't tell that much about the content either. I don't think the backend should do silent truncation, that would be very bad. It might be needed to have a flag for backends to allow it though. Joerg ___ 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 way too slow
On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: the same info is available on linux via /sys and /proc and on comparable hardware, i can get the info about 100x faster. Are you sure that Linux is not just caching the data? I know of at least one system where it takes more than 100ms to query the battery state due to extremely slow hardware, I wouldn't be surprised if you can do worse. Joerg ___ 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: Using lex in a shared library
On Fri, Jul 02, 2010 at 04:52:45PM -0700, Xin LI wrote: I think that amd64 requires a static library be compiled with -fPIC if it's being linked into shared object. This should not be done for normal static libraries, though, as this could give some performance penalty when it's not needed (i.e. a static binary). More precisely, AMD64 disallows absolute references in the text segment. The performance penalty for PIC on AMD64 is minimal as it can do RIP-relative addressing. Joerg ___ 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: Using lex in a shared library
On Fri, Jul 02, 2010 at 02:51:16PM -0700, Matthew Fleming wrote: LDADD=-ll Have you considered providing your own yywrap function instead? (Or not using it at all?) Joerg ___ 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: GSoC: BSD text tools
On Tue, May 25, 2010 at 05:06:58PM +0200, Julian H. Stacey wrote: Joerg Sonnenberger jo...@britannica.bec.de wrote: The use of (g)roff for anything but man pages is practically non-existent. False. Its a production tool used here. http://berklix.com./associates/ http://www.berklix.com/~jhs/cv/#card ( Try .PS card back X3 size All business letters, bills, business cards, ID cards, cdrom labels here use groff. There's guys recently wrote me from Germany developing groff macros for .de iso standard business letters to the new standard. ...and this are located in the source tree where exactly? Noone prevents you from installing groff or heirloom troff and using it. Pointing to the odd case of users (still) depending on it for typical needs is IMO more a confirmation of what I said and not really in disagreement. Joerg ___ 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: GSoC: BSD text tools
On Mon, May 24, 2010 at 12:13:07PM -0700, Charlie Kester wrote: I welcome this change, but groff is used for much more than manpages. What happens to pic, tbl, and the other troff-related little languages? How can you say mdocml is completely replacing groff if it doesn't support those kinds of things? tbl(1) is going to be supported fully at some point in the future. It is work-in-progress. I am not sure if pic(1) is actually used beyond the groff documentation, at least I don't remember anything in NetBSD where I checked. Similiar usage is found for eqn(1). Is the thinking that groff has only been in base to support manpages? If so, this project makes sense. But even so, some clarification of the intent is needed. The use of (g)roff for anything but man pages is practically non-existent. If you want to use it for typesetting, you can always install it. Joerg ___ 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: GSoC: BSD text tools
On Mon, May 24, 2010 at 10:43:37PM +0300, Kostik Belousov wrote: Would it support ps/dvi output ? Postscript output is the major goal of a GSoC project. Joerg ___ 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: libc NLS, NFS mounted /usr/local, DHCP, no default route causes hangs
On Fri, Apr 23, 2010 at 04:40:36PM +0200, Jilles Tjoelker wrote:
The patch:
Index: lib/libc/nls/msgcat.c
===
--- lib/libc/nls/msgcat.c (revision 206760)
+++ lib/libc/nls/msgcat.c (working copy)
@@ -138,6 +138,9 @@
lang = C;
}
+ if (strcmp(lang, C) == 0)
+ NLRETERR(ENOENT);
+
/* Try to get it from the cache first */
RLOCK(NLERR);
SLIST_FOREACH(np, cache, list) {
This is wrong. Just because you are in the C locale doesn't mean that
you don't have a message cataloge.
Joerg
___
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: c question
On Fri, Apr 23, 2010 at 06:18:46PM +0300, Eitan Adler wrote: - use a matrix is faster than use a linked list? For what? For insertion and deletion no - linked list is faster. For sequential access they are the same speed (forgetting look-ahead caching). For random access matrix is faster. Actually -- it depends. Removing the tail and inserting at tail is amortised constant time for arrays if done using the double-on-full trick. In that case, array can be the faster datastructure too. Joerg ___ 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: regenerating /var/db/pkg
On Thu, Apr 22, 2010 at 08:56:39AM -0500, Dan Rue wrote: We're starting to use SSDs for boot drives in our freebsd boxes. We'd like to have /var on a memory backed FS, but losing the package database on every reboot is troublesome. Tried using a symlink from /var/db/pkg to /usr/local/.pkgdb or so? Joerg ___ 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: nroff -man, .An Aq formatting
On Mon, Mar 22, 2010 at 03:05:52PM +, Christian Weisgerber wrote: And we probably have that usage in other man pages. It is not clear to me if the problem is the use of these characters for angle quotes or the use of .Aq for email addresses. I think the best option would be to sit down and adjust .Mt slightly to include the angle quotes and start to use that. E.g. make .Mt j...@example.com output j...@example.com It is supported by (old) versions of groff already, just without the angel quotes. Joerg ___ 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: GEOM_ULZMA
On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote: LZMA compression optimized for fast decompression. It is still measurable slower than gzip and it is certainly not free. Most hard disks have linear read times 10 MB/s but the decompression can easily need half a second even on a modern CPU. Joerg ___ 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: GEOM_ULZMA
On Thu, Mar 04, 2010 at 03:54:05PM +0100, Dimitry Andric wrote: On 2010-03-04 15:28, Joerg Sonnenberger wrote: It is still measurable slower than gzip and it is certainly not free. Ehm, the LZMA SDK is in the public domain, how much more free would you want it? Free as in time it takes, not free as in beer. Joerg ___ 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: GEOM_ULZMA
On Thu, Mar 04, 2010 at 04:38:31PM +0200, Alexandr Rybalko wrote: On Thu, 4 Mar 2010 15:28:19 +0100 Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote: LZMA compression optimized for fast decompression. It is still measurable slower than gzip and it is certainly not free. Most hard disks have linear read times 10 MB/s but the decompression can easily need half a second even on a modern CPU. No one says that it fast, but if you have only 4M of flash for CFE+kernel+rootfs+nvram, you must use something what make space usage smaller. Different domain :) Joerg ___ 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: GEOM_ULZMA
On Wed, Mar 03, 2010 at 08:29:14AM -0800, Tim Kientzle wrote: Adrian Chadd wrote: On 21 February 2010 02:20, Adrian Chadd adr...@freebsd.org wrote: Oh I know that! I'm just saying that I may try lzma'ing the kernel and rootfs's to see what kind of savings I get over gzip. :) The answer is whoa. 24 megabyte compressed kernel + MDROOT drops to 6.5 megabytes with gzip -9 and a few bytes shy of 5 megabytes with a default lzma compress. Interesting question: What is the impact on boot speed? It could be a lot faster to load 5MB from disk and decompress to a 24MB image than to wait for 24MB from disk. I don't think it helps in terms of boot speed, at least as long as the kernel image can be read without constant seeking. Joerg ___ 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: tar tfv /dev/cd0 speedup patch
On Thu, Feb 18, 2010 at 09:03:33PM -0800, Tim Kientzle wrote: Joerg Sonnenberger wrote: On Thu, Feb 18, 2010 at 07:34:59PM +0100, Juergen Lock wrote: Ok here is a new version of the patch with these things fixed and the Linux case added: (Linux case not tested yet, and yes I did this on stable/8.) Why the check at all? Shouldn't devices that don't allow seek fail that? E.g. for devices, just try to seek ahead and fallback to normal reading? That was the initial implementation in libarchive, but I had a number of reports of that not working for tape drives. I recently dug out and connected an old DDS drive I had in the closet, so I should probably try again and see if I misunderstood something along the way. I can think of some complications that for block devices the seek is to be a multiple of the block size (just like reads), but that's all I can think of in terms of portable problems. Joerg ___ 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: tar tfv /dev/cd0 speedup patch
On Thu, Feb 18, 2010 at 07:34:59PM +0100, Juergen Lock wrote: Ok here is a new version of the patch with these things fixed and the Linux case added: (Linux case not tested yet, and yes I did this on stable/8.) Why the check at all? Shouldn't devices that don't allow seek fail that? E.g. for devices, just try to seek ahead and fallback to normal reading? Joerg ___ 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 with regex?
On Wed, Feb 10, 2010 at 01:14:01PM +0100, Roman Divacky wrote: Formally, a regular expression is a textual representation of a finite state machine that describes a context-free grammar. I dont think so regular expressions describe regular languages which are a strict subset of context free languages. The sentence is still correct, strictly speaking :) Not all context-free grammars can be represented by a FSM, those that can be are the regular languages. Joerg ___ 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] extending/completing brandelf's OS knowledge
On Mon, Jan 25, 2010 at 11:16:25AM +0200, Kostik Belousov wrote: If static linux binary contains .note.ABI-tag section, and I believe that relatively modern binaries do, then brand is autodetected. Relatively modern means by default anything using glibc. Also a bunch of newer libc5 versions, I think. Joerg ___ 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: about zlib on FreeBSD
On Wed, Dec 02, 2009 at 01:01:38PM +, Vincent Hoffman wrote: To be fair, bsdtar(1) on my 8-STABLE box says it can read but not that it can create zipfiles. It it can create them that would be handy. The support for zip creation hasn't been merged yet. Joerg ___ 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: enable ECC in OS code?
On Thu, Aug 27, 2009 at 11:30:15AM +0800, Erich Dollansky wrote: how should it be done at OS level at all when the OS is loaded into RAM? Copy the kernel to the video RAM, jump to it, enable ECC, copy back. Joerg ___ 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: large pages (amd64)
On Sun, Jun 28, 2009 at 08:14:24PM -0400, Nathanael Hoyle wrote: Just to be clear, since you say i386 (I presume you mean architecture), I believe the Physical Address Extensions which allowed 2MB Page Size bit to be set was introduced with Pentium Pro. Processors prior to this were limited to standard 4KB pages. PSE != PAE != PSE36. Pentium Pro sounds about right though. Joerg ___ 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: close-on-exec alternatives (was: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls?)
On Tue, Jun 02, 2009 at 08:58:50PM +0200, Bernd Walter wrote: It is still very interesting, because I currently have a similar problem and wasn't aware of getdtablesize(); Note that many (other) systems provide a much simpler and efficient function for the above, closefrom(3). Joerg ___ 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: SoC 2009: BSD-licensed libiconv in base system
On Wed, May 06, 2009 at 02:28:51PM +0400, Alexander Churanov wrote: 1) Why discuss UCS-4 at all? UTF-32 is alreay in place. SImple, standardized, fixed-width and stateless. Which part of combining characters is stateless? Sure, you can ignore that in some/many applications, but it still exists. UCS-4 and UTF-32 are identical, so discussing one is enough. 2) I'm against using wchar_t internally, because C language standard does not require that a wchar_t variable can hold an UTF-32 code point. See my original point of that locale independent wchar_t might be useful, but creates problems. If the OS supports full Unicode 3+ locales, it will have to be able to fit any UCS-4 code point into wchar_t. Joerg ___ 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: NetBSD 5.0 statistics
On Thu, Apr 30, 2009 at 01:41:42PM -0700, Marcel Moolenaar wrote: I recall that our make -j X actually limits the number of make processes/jobs to X. I don't know anything about build.sh, so I don't know if our make is at all being involved, but it would be good to know how the load varies per OS. build.sh is using NetBSD's make for all but the tool build and the tool build is not included in the stats. Joerg ___ 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: Definition of NULL
On Mon, May 04, 2009 at 10:46:02AM -0400, John Baldwin wrote: I think this would be ok to let C++ work in the kernel. Embedded C++ (no exceptions and no dynamic_cast) should work fine in theory. I would not change the value of NULL that userland sees though as I think that may be too risky. Well, use __null if present all the time, fallback to the alternatives as currently defined. Joerg ___ 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: SoC 2009: BSD-licensed libiconv in base system
On Mon, Apr 27, 2009 at 10:42:46PM -0400, David Schultz wrote: On Mon, Apr 27, 2009, Joerg Sonnenberger wrote: On Mon, Apr 27, 2009 at 03:49:04PM -0400, David Schultz wrote: ...but isn't this moot at present because there are no widely-accepted encodings that include characters that aren't supported by UCS-4? Citrus doesn't seem to support any such encodings in any case. Just using UCS-4 not necessarily buys you the desired affect. Keep in mind that UCS-4 is still a variable width encoding, as soon as you factor combining characters and some other interesting parts in. This is true, but unfortunately C99 wasn't really designed to support combining characters. I don't understand how this relates to the present discussion. The main reason people want to use wchar_t is because they want to use a fixed width presentation of characters. Just using UCS-4 doesn't give you that if you ever want to support Level 2 and higher. It also highlights UCS-4 is not that state independent as it is often thought to be. That is again something undesirable. Joerg ___ 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: SoC 2009: BSD-licensed libiconv in base system
On Tue, Apr 28, 2009 at 11:08:49AM +0200, Gabor Kovesdan wrote: Citrus is based on UCS-4 as an internal encoding, just like the another BSD-licensed iconv library. This is a barrier to support encodings that aren't supported by UCS-4. More precisely is that Citrus can and will use UCS-4 as appropiate. It does not enforce it. Which is an important difference. One reason that it is often used is that it helps to avoid exponential growth of the translation tables. It just isn't worth the time to write ISO-8859-1 to ISO-8859-15 (trivial), if the translation to and from UCS4 gives the same result with marginally more work. It's possible that there are little poor countries with an own writing system but probably their writing system is unsupported because the starvation, poorness and lack of water and electricity are more serious problems there. I wouldn't call all both parts of Korea little poor countries and it is a wonderful example for why UCS 4 Level 1 can be problematic. Joerg ___ 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: SoC 2009: BSD-licensed libiconv in base system
On Tue, Apr 28, 2009 at 03:53:10PM +0200, G?bor K?vesd?n wrote: It's possible that there are little poor countries with an own writing system but probably their writing system is unsupported because the starvation, poorness and lack of water and electricity are more serious problems there. I wouldn't call all both parts of Korea little poor countries and it is a wonderful example for why UCS 4 Level 1 can be problematic. I didn't know about Korea. Then I insist even more on that Unicode should be extended to cover them instead of making implementation-specific solutions. Unicode covers Korean. It just violates the one logic character equals one UCS-4 character or however you want to put. More trivial example can be obtained when looking at both your and my name. Diacrets have historically been part of the character, but it is possible to use combining characters in unicode for the cleaner description. Joerg ___ 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: ACPI-fast default timecounter, but HPET 83% faster
On Mon, Apr 27, 2009 at 01:50:31AM +0200, Pieter de Goeje wrote: While fiddling with the sysctl kern.timecounter.hardware, I found out that on my system HPET is significantly faster than ACPI-fast. I did some extensive testing on a variety of AMD and Intel boards and never found a system where HPET is slower than ACPI-fast. In addition, HPET provides a higher resolution. Joerg ___ 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: SoC 2009: BSD-licensed libiconv in base system
On Mon, Apr 27, 2009 at 11:49:41AM -0700, Tim Kientzle wrote: David Schultz wrote: ... whether it would make more sense to standardize on something like UCS-4 for the internal representation. YES. Without this, wchar_t is useless. I strongly disagree. Everything can be represented as UCS-4 is a bad assumption, but something Americans and Europeans naturally don't have to care about. Joerg ___ 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: SoC 2009: BSD-licensed libiconv in base system
On Mon, Apr 27, 2009 at 03:49:04PM -0400, David Schultz wrote: ...but isn't this moot at present because there are no widely-accepted encodings that include characters that aren't supported by UCS-4? Citrus doesn't seem to support any such encodings in any case. Just using UCS-4 not necessarily buys you the desired affect. Keep in mind that UCS-4 is still a variable width encoding, as soon as you factor combining characters and some other interesting parts in. Joerg ___ 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: Improving the kernel/i386 timecounter performance (GSoC proposal)
On Mon, Mar 30, 2009 at 07:32:42AM +, Poul-Henning Kamp wrote: On systems where the ACPI or HPET hardware can be memory-mapped, I should be equally possible to map those read-only into userland processes. Both are IO memory and contain other data. There is also the question of how undefined is implemented for locked bus cycles to them... Joerg ___ 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: Spin down HDD after disk sync or before power off
On Mon, Mar 09, 2009 at 04:17:15PM -0600, Rick C. Petty wrote: What I was hoping is that someone could point me to the spinup command as I have a drive which does not spin up until it receives this command. Any takers? There is no such command. Disks are supposed to spin up at the first read/write automatically. It can take a while though. Joerg ___ 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: Spin down HDD after disk sync or before power off
On Thu, Mar 05, 2009 at 08:58:50AM +0100, Oliver Fromme wrote: This is not true. Many hard disks don't like having to do an emergency shutdown as it affects the disk life time negatively. That's what happens if you poweroff the machine when the disks are still spinning. Can you point to any authoritative information (URL) about that claim, such as vendor specs, white paper or similar? Not without digging. NetBSD PR 21531 had a reference, but that is dead nowadays. Joerg ___ 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: Spin down HDD after disk sync or before power off
On Thu, Mar 05, 2009 at 11:49:10AM -0800, Nate Eldredge wrote: This makes sense in some ways. Suppose the drive is attached to a weird ATA controller that FreeBSD doesn't know anything about. (Maybe it's used by the other system in a dual-boot setup.) There's no way that FreeBSD could send it a power-down sequence, but the BIOS could. As long as you can send a ATA command directly to the disk, you can spin it down. Joerg ___ 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: Spin down HDD after disk sync or before power off
On Wed, Mar 04, 2009 at 08:38:52PM +0100, Oliver Fromme wrote: Octavian Covalschi wrote: I'm looking a way to spin down HDD just right before power off. Why? Because currently when I call shutdown -p now, HDD is powered off at it's full speed (7200.4) and as a result I hear a noise of stopping/spinning down of HDD, and _this_ concerns me as I'm afraid it can damage HDD. You don't have to spin down a disk before powering it off. The noise you hear is probably caused by the autopark feature of the drive. It is harmless. This is not true. Many hard disks don't like having to do an emergency shutdown as it affects the disk life time negatively. That's what happens if you poweroff the machine when the disks are still spinning. Joerg ___ 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: lzma compression/decompression in bsdtar/libarchive?
On Tue, Nov 25, 2008 at 10:56:24AM -0800, bf wrote: ?? Have you looked at this code? Yes, there is: there is an LZMA compressed file format and the 7z file format, both of which support LZMA. The former format has been widely adopted by people who distribute lzma-compressed tarballs, especially GNU-related projects that use the lzmautils port. Some projects, like GNU coreutils, no longer distribute the latest versions of their software in bzip2-compressed tarballs. lzma files in the current form are a major PITA. The format doesn't have a proper header and therefore is not really autodetectable. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel 5100 WiFi
On Sun, Nov 16, 2008 at 09:19:49PM -0500, jT wrote: Yes it will require a firmware blob as the 4965 one does. You are required to take notice to the legal aspects of the blob via setting a key in loader.conf. The firmware blob here is simply a large binary file that is loaded directly into the card memory. Contrary to the image for first and second generation Centrino, Intel changed to license to a BSDish license, so no further user interaction is needed to accept an EULA. Note that this image is run on the card, not your CPU. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: assigning interrupts
On Thu, Nov 13, 2008 at 02:40:54AM -0800, Jeremy Chadwick wrote: Otherwise, consider purchasing a motherboard that has an APIC (this is not a typo) increasing the IRQ count to 256. This is wrong. The first IO-APIC gives you 8 additional interrupts to the 16 ISA interrupt lines. Every additional IO-APIC gives you 24 more. Most modern chipsets have one IO-APIC, at least for non-embedded systems. It doesn't mean you don't get interrupt sharing though. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: assigning interrupts
On Thu, Nov 13, 2008 at 08:56:31AM -0800, Jeremy Chadwick wrote: Regarding it means you can still get interrupt sharing, I'd like to hear more about why/how that's possible with a system sporting at least one I/O APIC. You still have a limited number of interrupt lines. Many non-highend mainboards have 4 or 8 interrupt lines. You often have more than 8 PCI devices that want interrupts (e.g. VGA, audio, 3 USB controllers, 1 EHCI contoller and the SATA controller are enough to consume all lines). As soon as you now add a new network devices, you end up sharing PCI lines. The IO-APIC wiring is also often fixed, so it can't be controlled by software. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LIST_REMOVE problem
On Fri, Nov 07, 2008 at 10:07:17PM +0300, Sergey Matveychuk wrote: If we'll take a look at code, LIST_REMOVE don't change a head pointer if you remove the first element: It does via le_priv. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: open(2) and O_NOATIME
On Thu, Oct 30, 2008 at 07:16:42PM -0700, Xin LI wrote: Em... Allowing administrators to disable NOATIME would be a good thing, but wouldn't allowing arbitrary program to decide whether atime should be changed, be a serious security disaster? Think of backup programs. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Calling malloc from a signal handler
On Fri, Sep 19, 2008 at 08:52:13AM -0500, Stephen Montgomery-Smith wrote: Is it now permissible to call malloc from within a signal handler in FreeBSD-7.x? No. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop suggestions?
On Wed, Jul 30, 2008 at 04:31:10PM -0400, L Campbell wrote: It depends on what you consider to be comfortable. My primary machine is an old Dell Inspiron 6000 (running the RELENG_7 branch) and the only hardware compatibility issue I've ever had was that suspend/hibernate doesn't work (display doesn't come back on). vbetool post? Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop suggestions?
On Thu, Jul 31, 2008 at 08:25:04AM +0800, Wilkinson, Alex wrote: vbetool post? Is vbetool in ports ? I cant find it mentioned anywhere in INDEX-*. Can't find it either. ENOFREEBSD :) http://www.codon.org.uk/~mjg59/vbetool/ Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop suggestions?
On Sun, Jul 27, 2008 at 05:23:46PM -0400, Zaphod Beeblebrox wrote: That said, an OS-level suspend-to-disk would be an awesome summer-of-code project. I don't think it is feasible as SoC project without previous knowledge and interaction with at least the ACPI suspend-to-RAM code (or alternative the low-level boot code) and VM knowledge (both MI and MD). I believe it can be done in 3 month though. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Laptop suggestions?
On Fri, Jul 25, 2008 at 11:00:38PM +1000, Peter Jeremy wrote: Successive generations of laptops have become less and less free-OS-friendly. This is simply wrong. Most laptops ship either with Ati or Intel chipset. Both tend to be well supported. With a bit care, you will get wpi as wireless chipset (e.g. avoid draft n). I found ACPI compliance to have improved a lot over the recent time and in fact the number of ACPI bugs that can't be worked around in general ways has become very low. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
On Sun, Jun 15, 2008 at 09:11:36PM -0700, Garrett Cooper wrote: Now all we need to do is write / import a BSD compatible less(1) into FreeBSD =). less is dual licensed. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BDB corrupt
On Tue, May 13, 2008 at 03:44:06PM +0400, Anthony Pankov wrote: 3. reading/writing = 60%/40% I don't know where you get those numbers from, but they feel *very* wrong from the perspective of someone who actually dealt a lot with those tools. Writing is only a very small part of the operations and typically done a single large batch. For the same reason a single reader/writer lock is perfective fine. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
On Mon, May 12, 2008 at 08:47:53AM -0700, Jeremy Chadwick wrote: Secondly, the following FAQ entry and documentation from Mozilla is of concern, specifically the last paragraph of the FAQ entry, since there is ongoing work in the ports collection to support parallel building, which would surely use fork() or locks): I don't think this is applicable. Thirdly, there is the concern of disk space. There are a substantial number of users who have FreeBSD on embedded systems or systems with little or no space, who use binary packages (pkg_add -r), which of course still makes use of /var/db/pkg. SQLite DBs grow over time, and don't shrink in size unless you use auto-vacuum mode or execute the VACUUM query: It is trivial to recreate the database, so I don't think this is a concern either. I should point again that it will result in a non-trivial increase in size. Fourthly, it doesn't sound as if storage SQLite databases on an NFS mount is a good idea, and I've a feeling some people have /var NFS mounted (diskless systems for example): Same applies to BDB and basically anything that depends on fcntl to work. Basically, as long as you have /var per host (you don't share /var, do you?), it will just work as the *local* locks are working. The problem with NFS comes form the fact that multiple hosts might not share them. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
On Fri, May 09, 2008 at 01:52:46PM +0200, Anders Nore wrote: I'm working on adding .db support to the pkg_tools( i.e. pkg_add, pkg_info, etc. ) as part of SoC 2008. The database api used is BerkeleyDB that comes with the base system (/usr/src/include/db.h). BerkeleyDB is not you're typical relational db, and can only save key/value pairs. The way I'm thinking of storing information to the .db is to name the keys as the directory names in /var/db/pkg. And save the +* files in the directories to the value element in the db, separated with a special character or similar. As one of the persons hacking on pkg_install in pkgsrc/NetBSD, I would *strongly* advisy you against storing the files only in a bdb file. The change of major and complete corruption with bdb185 is high, consider pulling the plug in the middle of a long update. Secondly, I would also advisy against just storing all meta data in a single key/value pair. For example, +CONTENTS can be extremely large. Check texmf for a good example. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
On Fri, May 09, 2008 at 06:50:10PM +0200, Anders Nore wrote: Yes that would probably be bad for the database, but I'm sure one can manage to get around this problem by copying it before changing the db and delete the copy if it doesn't fail. At the next time executed it will check for a copy, use that and assume that the last run was unsuccessful. /var/db/pkg contains 10MB for the various packages installed on my laptop and 10MB for the cache of +CONTENTS. You don't want to copy that around all the time. Secondly, I would also advisy against just storing all meta data in a single key/value pair. For example, +CONTENTS can be extremely large. Check texmf for a good example. When it comes to storing large values in a key/value pair, I think that's what bdb was designed for, handling large amounts of data (in the orders of gigabytes even in key's) fast. No, actually that is exactly what it was *not* designed for. Having billions of keys is fine, but data that exceeds the size of a database page is going to slow down. While it might not be a problem of you are copying the data to a new file anyway, it also means that fragmentation in the database will be more problematic. My main point is that for the interesting operations you want to actually look up with fine grained keys and that's what is not possible if you store the meta data as blob. In fact, storing the meta data as blob is not faster than just using the filesystem. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding .db support to pkg_tools
On Fri, May 09, 2008 at 07:54:40PM +0200, Anders Nore wrote: You are probably right, but how would you store the key's? Is storing the key as e.g., 'portname-1.2_3+CONTENT' a good solution? I'd just use a different db file. I am not sure how much the following applies to FreeBSD as pkg_install has diverted a lot. The most expensive operations during pkg_add and pkg_info are scans for conflicts (explicit via @pkgcfl or implicit due to overlapping file lists) as they need to compare the to-be-installed package with all existing ones. After that come directory scans to resolve dependencies. Everything else is really just open this small file and extract some data from it, where small usually means less than one block. Putting that into a database can help or not, but I don't think it is relevant. So the most important operations to support a btree of all files (implemented in NetBSD/pkgsrc) and a btree of all @pkgcfl/@pkgdb (not implemented yet). Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CopyOut Size Limits
On Fri, Apr 25, 2008 at 09:59:55AM -0400, Adam wrote: Hi, I am writing a custom system call that needs to transfer 16kb of data from the kernel to userspace. I am transferring the data out of the kernel by using copyout. This seems to work for a small struct of data 4k. You are not allowed to use more than a bit of stack space. You are placing a of data on the stack and the kernel stack is typically only a few pages long. Use malloc for this. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: visualize kernel memory allocations
On Tue, Apr 15, 2008 at 08:06:28PM +1000, Peter Jeremy wrote: About all I can suggest is working out the return address and finding which module that exists within. That doesn't sound particularly nice. Search gcc's info file for __builtin_return_address for the first part. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: features of objcopy
On Fri, Mar 21, 2008 at 09:03:19PM +0100, Kai Wang wrote: 1. Do you often use object/strip on 'ar' archives? Strip on ar(1)chives is very handy. 2. Do you often convert ELF to raw binary, iHex, S-Record or vice versa? Not via objcopy, but with ld. 3. What features do you like to add into objcopy? Proper support to add loadable sections that end up in the header as well. Consider loadable memory disk images as part of the kernel without having to preallocate the space. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't autoconf like our /bin/sh?
On Sun, Mar 09, 2008 at 07:40:50PM -0400, Mike Meyer wrote: 1) Our /bin/sh isn't classified as Definitely usable. 2) zsh is Not usable. 3) zsh is classified as Maybe usable. The third is definitely true. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libpthread/fork issue
On Thu, Mar 06, 2008 at 09:45:15PM -0600, Marko, Shaun wrote: In short, if a process creates a thread, joins the thread, then forks a child process which creates a thread, the child's attempt to create a thread will cause the program to dump core with the following error message. fork and pthread should not be mixed. You can and normally should only assume that the current thread is present in the child. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wpi -- periodic disconnections
On Wed, Mar 05, 2008 at 12:58:06AM +0100, Pietro Cerutti wrote: - I've been able to reconnect without kld-reloading the module, by killing and restarting wpa_supplicant Try disconnect followed by reconnect. I have a similiar problem in NetBSD I am tracking down currently. It happens a lot more often in WPA mode (compared to WPA2). Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wpi -- periodic disconnections
On Wed, Mar 05, 2008 at 01:20:33AM +0100, Pietro Cerutti wrote: Joerg Sonnenberger wrote: On Wed, Mar 05, 2008 at 12:58:06AM +0100, Pietro Cerutti wrote: - I've been able to reconnect without kld-reloading the module, by killing and restarting wpa_supplicant Try disconnect followed by reconnect. Sorry, what do you mean? wpa_cli. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: emulate an end-of-media
On Tue, Feb 26, 2008 at 04:00:00PM -0500, Mike Meyer wrote: On Tue, 26 Feb 2008 21:28:53 +0100 Joerg Sonnenberger [EMAIL PROTECTED] wrote: On Tue, Feb 26, 2008 at 07:44:48PM +0100, Martin Laabs wrote: I also made a comparison between gzip and bzip2 regarding the compression ratio on a dump of my home directory (3.2GB) bzip2 took about 74min to compress, gzip only 11minutes. And in terms of compression ratio bzip2 was only 3% better than gzip. That's not a realistic test case. bzip2 normally takes trice the time and compresses 10% better. I can't comment on compress. Considering we're talking about compression methods to use on dump output, that would seem to be the definition of a realistic test case. Telling us what it normally does without defining what input is considered normal doesn't help much. Source code in my case and various other documents. The test case above certainly was not normal. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: emulate an end-of-media
On Tue, Feb 26, 2008 at 07:44:48PM +0100, Martin Laabs wrote: I also made a comparison between gzip and bzip2 regarding the compression ratio on a dump of my home directory (3.2GB) bzip2 took about 74min to compress, gzip only 11minutes. And in terms of compression ratio bzip2 was only 3% better than gzip. That's not a realistic test case. bzip2 normally takes trice the time and compresses 10% better. I can't comment on compress. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OT: Stream structures in bzlib and zlib
On Thu, Feb 21, 2008 at 10:53:15AM +0100, Heiko Wundram (Beenic) wrote: Before I go and test whether bzlib modifies the input buffer for temporaries (by simply passing it data in a RO segment and checking whether I get a SIGSEGV), is there anyone out there who's hit the same problem before and might shed some more insight whether I'll have to copy the data before setting it up in a stream structure as input? The buffers are not modified for the compression path. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote: Mind you, it's true that disabling core dumps with a resource limit doesn't keep one from creating a core image using gcore, but since gcore generally must either attach to a process using ptrace() or access mapped code segments in the original binary (depending on the implementation), it won't help in such a case, either. What prevents me from patching the kernel (!) to just ignore the resource limit? Nothing. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sort(1) memory usage
On Mon, Feb 04, 2008 at 04:04:35PM +0100, Dag-Erling Sm?rgrav wrote: Last I checked, it also (rather surprisingly) lacked -u (unique), which is required by POSIX. That must have been before the import into src/usr.bin/sort in 2000. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wrapper for Windows-only network card binary drivers on FreeBSD?
On Thu, Jan 24, 2008 at 04:12:00PM -0800, Yuri wrote: I am curious is there an effort in FreeBSD similar to Linux NDISwrapper? man 4 ndis Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gettimeofday() in hping
On Tue, Jan 22, 2008 at 03:34:55PM +0100, Dag-Erling Sm?rgrav wrote: More modern machines have an HPET timer which is supposedly faster than ACPI yet more reliable than TSC. For NetBSD on AMD64 on a 1.2GHz Core2: ACPI ~2400 cycles HPET ~1500 cycles TSC ~800 cycles clockinterrupt ~600 cycles Those are from memory, give or take 10%. This is for the gettimeofday system call. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Architectures with strict alignment?
On Sat, Dec 29, 2007 at 06:03:15PM +0800, Erich Dollansky wrote: I also do not know of any other CISC based design which made it to mainstream. VAX? Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kqueue and libev
On Sat, Dec 15, 2007 at 09:51:20AM +, James Mansion wrote: Kqueue deserves special mention, as at the time of this writing, it was broken on all BSDs except NetBSD (usually it doesn't work with anything but sockets and pipes, except on Darwin, where of course its completely useless). You normally don't get useful writeable/readable state for files, if that is what the author means. This is the same situation as you have with poll(2) and select(2) though. Otherwise I can't think of what he could mean. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memory pool, rfc
On Thu, Nov 01, 2007 at 01:05:54AM +0100, Eduardo Morras wrote: Don't point me to zlib or libbzip2, they are on another league and are much slower than my code. Have you looked at liblzo? Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Exclusive binary files
On Sat, Sep 01, 2007 at 06:30:20PM -0400, Mike Meyer wrote: On Sat, 1 Sep 2007 14:27:42 -0300 Klaus Schneider [EMAIL PROTECTED] wrote: Well, anybody know a way to make the FreeBSD run just binaries that I have compiled? In general, it's impossible. There's no way the system can know that you compiled a binary. There are a number of things you could do with a custom kernel and toolchain to indicate that you compiled the binary (like Peter's changing of ELF OSABI), but that's just security through obscurity. If someone figures out those changes and replicates them, you lose. You mean using cryptographic hashes to ensure that binaries match those you compiled is impossible? Something like NetBSD's veriexec? Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
