Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)?
Hello, Freebsd-hackers. Does FreeBSD have some custom call, which can be used where Linux programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? It is like madvise(2) but for file descriptors. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)?
On Thu, May 12, 2011 at 11:38:12AM +0400, Lev Serebryakov wrote: Hello, Freebsd-hackers. Does FreeBSD have some custom call, which can be used where Linux programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? It is like madvise(2) but for file descriptors. No, it does not (and I think the function is spelled posix_fadvise()). mdf reserved the syscall slot for posix_fadvise in his recent work on posix_fallocate(). Might be, he could comment more. pgpeURQwJNk0Q.pgp Description: PGP signature
Re: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)?
On Thu, May 12, 2011 at 4:17 AM, Kostik Belousov kostik...@gmail.com wrote: On Thu, May 12, 2011 at 11:38:12AM +0400, Lev Serebryakov wrote: Hello, Freebsd-hackers. Does FreeBSD have some custom call, which can be used where Linux programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? It is like madvise(2) but for file descriptors. No, it does not (and I think the function is spelled posix_fadvise()). mdf reserved the syscall slot for posix_fadvise in his recent work on posix_fallocate(). Might be, he could comment more. Whoops, I replied bot forgot to reply-all. Adding a stub for posix_fadvise() is on my list of things to do, since we use it at $WORK in our custom filesystem, but the list is long and spare time is short. Nominally a technically correct implementation can do error checking and then nothing. Even after a stub is added to the OS, each filesystem must implement a VOP to do the work. Cheers, matthew ___ 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: [UPDATE] New Boot-Loader Menu -- version 1.3
On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: Devin Teske dte...@vicor.com wrote: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Devin, have you thought about writing a port [1]? I'd be happy to review it: [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html I'm going to see if I can't make it perfectly acceptable for base first. If the final version gets rejected for submission to base, I'll turn to ports. On a side-note, it'd be a pretty interesting port... considering the fact that I'm already distributing it as a FreeBSD package (what would the Makefile for that port look like... a call to fetch followed by a call to pkg_add ?? lol -- are there other ports that already work like that?). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ ___ 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: [UPDATE] New Boot-Loader Menu -- version 1.3
On May 12, 2011, at 2:14 PM, Devin Teske wrote: On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: Devin Teske dte...@vicor.com wrote: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Devin, have you thought about writing a port [1]? I'd be happy to review it: [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html I'm going to see if I can't make it perfectly acceptable for base first. If the final version gets rejected for submission to base, I'll turn to ports. On a side-note, it'd be a pretty interesting port... considering the fact that I'm already distributing it as a FreeBSD package (what would the Makefile for that port look like... a call to fetch followed by a call to pkg_add ?? lol -- are there other ports that already work like that?). In the FreeBSD developer's summit today, there was broad support for bringing it into base for 9.0. Warner ___ 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: [UPDATE] New Boot-Loader Menu -- version 1.3
On 5/12/11 2:14 PM, Devin Teske wrote: On May 4, 2011, at 1:37 AM, Emanuel Haupt wrote: Devin Teskedte...@vicor.com wrote: Hey all, Proud to bring you version 1.3 which completes the followup suggestions made by Olivier Smedts (use autoboot_delay instead of loader_menu_timeout and change dc_seconds to loader_delay) and a couple other minor enhancements/fixes. I think that brings everything up to speed with the phenomenal feedback provided so far. Really, thank you all very much. Get your update at http://druidbsd.sf.net/ or http://druidbsd.sourceforge.net/download/loader_menu-1.3.tgz Devin, have you thought about writing a port [1]? I'd be happy to review it: port would be good for 8 it'll be in 9 by default (we just decided a the devsummit) (if there are no roadblocks) [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/own-port.html I'm going to see if I can't make it perfectly acceptable for base first. If the final version gets rejected for submission to base, I'll turn to ports. On a side-note, it'd be a pretty interesting port... considering the fact that I'm already distributing it as a FreeBSD package (what would the Makefile for that port look like... a call to fetch followed by a call to pkg_add ?? lol -- are there other ports that already work like that?). Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. ___ 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: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)?
2011/5/12 Lev Serebryakov l...@serebryakov.spb.ru: Hello, Mdf. You wrote 12 мая 2011 г., 15:40:25: Does FreeBSD have some custom call, which can be used where Linux programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? It is like madvise(2) but for file descriptors. No, it does not (and I think the function is spelled posix_fadvise()). mdf reserved the syscall slot for posix_fadvise in his recent work on posix_fallocate(). Might be, he could comment more. Whoops, I replied bot forgot to reply-all. Adding a stub for posix_fadvise() is on my list of things to do, since we use it at $WORK in our custom filesystem, but the list is long and spare time is short. Nominally a technically correct implementation can do error checking and then nothing. Even after a stub is added to the OS, each filesystem must implement a VOP to do the work. transmission Torrents client rely on this syscall. It could be beuilt without it, of course (it is in our ports!), but it seems, that it produce much more sane disk load on Linux, because uses pre-fetch via posix_fadvise(). My profiling shows that pread() could take about 40% of it CPU time (8 seconds out of 20 with turned on ktrace, for example), even if throughput is very modest (700KiB/s, for example). Authors say, that they didn't observe such behavior on Linux (which has posix_fadvise()) or MacOS X (with fcntl(F_RDADVISE))... May be, we should go to fs@ with this thread now? Probably; the interface and a few unit tests are a start but the common filesystems (presumably ufs and zfs and perhaps others) will need support and I do not have any knowledge of the internals of those filesystems. Cheers, matthew ___ 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
OpenGrok for FreeBSD
Hello List, I've set up an OpenGrok service for the FreeBSD sources (current). OpenGrok is a source code search engine and cross reference. I'm updating the sources once a day. I'm a NetBSD developer and I'm also maintaining http://nxr.netbsd.org Feel free to use it: http://fxr.aydogan.net Cheers, Zafer. ___ 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
lldb patches for FreeBSD
Hi, I installed FreeBSD 8.2 amd64 and trying to see how far lldb compiles, seeing as OpenBSD lacks shm_open/shm_unlink and some posix shared memory functionality right now. Note: FreeBSD 8.2 amd64 has system gcc of 4.2.1, the last GPLv2 gcc with some patches before the switch to GPLv3, if I am not mistaken. It seems FreeBSD is also affected like OpenBSD about the thread id issue discussed a month before in this thread. I am cc'ing matthew@ just to keep him in the loop. http://lists.cs.uiuc.edu/pipermail/lldb-dev/2011-April/000444.html and it was resolved to fix it like so http://lists.cs.uiuc.edu/pipermail/lldb-dev/2011-April/000452.html I don't know what should be the replacement for FreeBSD, as that particular piece of code in lldb/source/Host/common/Host.cpp is a dirty hack to allow compile to proceed. This is not okay to include otherwise. http://svnweb.FreeBSD.org/base/head/lib/libc/include/namespace.h?r1=214093r2=218414 Can somebody from freebsd-hackers speak up? Or just give the correct diff for FreeBSD? I am stuck in this for now. I will take it up later. /stuff/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:1471: error: ISO C++ forbids variable-size array 'params' Here's what I got so far, small things all related to compile. Thanks, amit Index: include/lldb/Host/Host.h === --- include/lldb/Host/Host.h(revision 131240) +++ include/lldb/Host/Host.h(working copy) @@ -352,6 +352,15 @@ static lldb::pid_t LaunchApplication (const FileSpec app_file_spec); +static lldb::pid_t +LaunchInNewTerminal (const char *tty_name, + const char **argv, + const char **envp, + const char *working_dir, + const ArchSpec *arch_spec, + bool stop_at_entry, + bool disable_aslr); + static Error LaunchProcess (ProcessLaunchInfo launch_info); Index: source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h === --- source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h (revision 131240) +++ source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h (working copy) @@ -11,6 +11,9 @@ #define liblldb_PlatformRemoteGDBServer_h_ // C Includes +#if defined (__OpenBSD__) + #include sys/param.h +#endif // C++ Includes #include string Index: source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h === --- source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h (revision 131240) +++ source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h (working copy) @@ -72,7 +72,7 @@ dwarf_ymm4 = dwarf_xmm4, dwarf_ymm5 = dwarf_xmm5, dwarf_ymm6 = dwarf_xmm6, -dwarf_ymm7 = dwarf_xmm7, +dwarf_ymm7 = dwarf_xmm7 }; enum Index: source/Interpreter/OptionGroupFormat.cpp === --- source/Interpreter/OptionGroupFormat.cpp(revision 131240) +++ source/Interpreter/OptionGroupFormat.cpp(working copy) @@ -7,7 +7,7 @@ // //===--===// -#include OptionGroupFormat.h +#include lldb/Interpreter/OptionGroupFormat.h // C Includes // C++ Includes Index: source/Interpreter/OptionGroupValueObjectDisplay.cpp === --- source/Interpreter/OptionGroupValueObjectDisplay.cpp(revision 131240) +++ source/Interpreter/OptionGroupValueObjectDisplay.cpp(working copy) @@ -7,7 +7,7 @@ // //===--===// -#include OptionGroupValueObjectDisplay.h +#include lldb/Interpreter/OptionGroupValueObjectDisplay.h // C Includes // C++ Includes @@ -123,4 +123,4 @@ // If we don't have any targets, then dynamic values won't do us much good. use_dynamic = lldb::eNoDynamicValues; } -} \ No newline at end of file +} Index: source/Interpreter/OptionGroupUInt64.cpp === --- source/Interpreter/OptionGroupUInt64.cpp(revision 131240) +++ source/Interpreter/OptionGroupUInt64.cpp(working copy) @@ -7,7 +7,7 @@ // //===--===// -#include OptionGroupUInt64.h +#include lldb/Interpreter/OptionGroupUInt64.h // C Includes // C++ Includes Index: source/Interpreter/OptionGroupOutputFile.cpp === --- source/Interpreter/OptionGroupOutputFile.cpp(revision 131240) +++ source/Interpreter/OptionGroupOutputFile.cpp(working copy) @@ -7,7 +7,7 @@ // //===--===// -#include
Re: Does FreeBSD have replacement for posix_fadvice() or fcntl(F_RDADVISE)?
On Thu, May 12, 2011 at 11:38:12AM +0400, Lev Serebryakov wrote: Does FreeBSD have some custom call, which can be used where Linux programs uses posix_fadvice() and DARWIN ones fcntl(F_RDADVISE)? It is like madvise(2) but for file descriptors. An effect like POSIX_FADV_SEQUENTIAL can be obtained with the F_READAHEAD or F_RDAHEAD fcntl(2) requests. The implementation is divided between the generic VFS layer and various filesystems (cd9660, ext2fs, msdosfs, nfs, xfs and ufs appear to use the information to some degree). Setting readahead to 0 with the fcntl requests has little effect: it resets the state of the sequential access detection heuristic but does not disable it. The O_DIRECT open(2) flag has an effect similar to what POSIX_FADV_NOREUSE should do, except that it changes semantics by adding alignment restrictions. -- Jilles Tjoelker ___ 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: lldb patches for FreeBSD
On Friday 13 May 2011 00:00:28 Amit Kulkarni wrote: It seems FreeBSD is also affected like OpenBSD about the thread id issue discussed a month before in this thread. I am cc'ing matthew@ just to keep him in the loop. http://lists.cs.uiuc.edu/pipermail/lldb-dev/2011-April/000444.html Check out this code from FreeBSD's OpenJDK6 port: #if __FreeBSD_version 900030 return pthread_getthreadid_np(); #else long tid; thr_self(tid); return (pid_t)tid; #endif The underlying type of a tid (lwpid_t in kernel) is an int. -- Pieter de Goeje ___ 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
