the Newcons Project
My understanding of this whole subject is limited, but bear with me... in my quest to get a cool looking console for my desktop... I found this https://wiki.freebsd.org/Newcons does anyone know if someone is still actively working on the NewCons project? or is it already committed to HEAD and i just don't realize? the wiki is a bit confusing... I would VERY much be able to have a console that looked like this in FreeBSD http://wiki.gentoo.org/images/7/7c/Bootsplash.png but if my understanding is correct, we are not at this point (yet)... even if you pull the development source from here svn co svn://svn.freebsd.org/base/user/ed/newcons and change the kernel config like this: #device vga # VGA video card driver #device sc device vt device vt_vga could someone with more understanding of this, be able to tell me if the Newcons project (when completed) is even going to do what i'm looking for? if so, exactly what things have to be done yet, in order for FreeBSD to have a console like Gentoo? -- Sam Fourman Jr. ___ 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
clang: -mno-omit-leaf-frame-pointer
It seems that, unlike gcc, for clang -fno-omit-frame-pointer does not imply
-mno-omit-leaf-frame-pointer. This is probably a bug.
Meanwhile I would like to propose the following amd64-specific patch. Perhaps
the same type of change would be useful for powerpc as well.
I would like this change primarily for DTrace (fbt), but other
debugging/profiling code may benefit from it as well.
I chose to make -mno-omit-leaf-frame-pointer not conditional on clang, because
with gcc it is just a nop (i.e. it doesn't hurt anything).
--- a/sys/conf/Makefile.amd64
+++ b/sys/conf/Makefile.amd64
@@ -32,7 +32,7 @@ S=../../..
.include $S/conf/kern.pre.mk
.if !empty(DDB_ENABLED) || !empty(DTR_ENABLED) || !empty(HWPMC_ENABLED)
-CFLAGS+= -fno-omit-frame-pointer
+CFLAGS+= -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
.endif
MKMODULESENV+= MACHINE=amd64
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
index f0d3d4d..7eaba85 100644
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -122,7 +122,7 @@ LDFLAGS+= -d -warn-common
CFLAGS+= ${DEBUG_FLAGS}
.if ${MACHINE_CPUARCH} == amd64
-CFLAGS+= -fno-omit-frame-pointer
+CFLAGS+= -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
.endif
.if ${MACHINE_CPUARCH} == powerpc
--
Andriy Gapon
___
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: big change to devfs rules path matching
On 2013-03-28, Andriy Gapon wrote: Would like to ask for opinions on this topic... Please read this PR for context: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 Especially Jaakko's insightful description of the problem. So I would like to commit the following patch sooner rather than later: http://people.freebsd.org/~avg/devfs_rule.diff The only difference from the Jaakko's patch in the PR is FNM_PATHNAME. Please review and test. Good to see this moving forward! Maybe the change warrants an UPDATING entry? -- Jaakko ___ 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(2) while accept(2) is blocked
Bakul Shah wrote this message on Fri, Mar 29, 2013 at 16:54 -0700: On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro carl.shap...@gmail.com wrote: In other operating systems, such as Solaris and MacOS X, closing the descriptor causes blocked system calls to return with an error. What happens if you select() on a socket and another thread closes this socket? Ideally select() should return (with EINTR?) so that the blocking thread can some cleanup action. And if you do that, the blocking accept() case is not really different. There is no point in *not* telling blocking threads that the descriptor they're waiting on is one EBADF and nothing is going to happen. It is not obvious whether there is any benefit to having the current blocking behaviour. This may need some new kernel code but IMHO this is worth fixing. As someone else pointed out in this thread, if a userland program depends upon this behavior, it has a race condition in it... Thread 1Thread 2Thread 3 enters routine to read enters routine to close calls close(3) open() returns 3 does read(3) for orignal fd How can the original threaded program ensure that thread 2 doesn't create a new fd in between? So even if you use a lock, this won't help, because as far as I know, there is no enter read and unlock mutex call yet... I decided long ago that this is only solvable by proper use of locking and ensuring that if you call close (the syscall), that you do not have any other thread that may use the fd. It's the close routine's (not syscall) function to make sure it locks out other threads and all other are out of the code path that will use the fd before it calls close.. If someone could describe how this new eject a person from read could be done in a race safe way, then I'd say go ahead w/ it... Otherwise we're just moving the race around, and letting people think that they have solved the problem when they haven't... I think I remeber another thread about this from a year or two ago, but I couldn't find it... If someone finds it, posting a link would be nice.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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(2) while accept(2) is blocked
As someone else pointed out in this thread, if a userland program depends upon this behavior, it has a race condition in it... Thread 1 Thread 2Thread 3 enters routine to read enters routine to close calls close(3) open() returns 3 does read(3) for orignal fd How can the original threaded program ensure that thread 2 doesn't create a new fd in between? So even if you use a lock, this won't help, because as far as I know, there is no enter read and unlock mutex call yet... I decided long ago that this is only solvable by proper use of locking and ensuring that if you call close (the syscall), that you do not have any other thread that may use the fd. It's the close routine's (not syscall) function to make sure it locks out other threads and all other are out of the code path that will use the fd before it calls close.. If someone could describe how this new eject a person from read could be done in a race safe way, then I'd say go ahead w/ it... Otherwise we're just moving the race around, and letting people think that they have solved the problem when they haven't... Right. The only safe way is to have all blocking syscalls on the same fd in the same process return to userland. This would need to be initiated in the close() syscall. Btw. Threads aren't the only scenario. A signal handler can also close the fd. Maybe not advised, but I have used this technique to force a return from a blocking accept() call since about FBSD4.x Mark. ___ 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: -mno-omit-leaf-frame-pointer
On Mar 30, 2013, at 09:10, Andriy Gapon a...@freebsd.org wrote: It seems that, unlike gcc, for clang -fno-omit-frame-pointer does not imply -mno-omit-leaf-frame-pointer. This is probably a bug. Yes, this is indeed the case. There is even a rather old unresolved PR for it in LLVM's Bugzilla: http://llvm.org/bugs/show_bug.cgi?id=9825 Meanwhile I would like to propose the following amd64-specific patch. Perhaps the same type of change would be useful for powerpc as well. Most likely yes. I would like this change primarily for DTrace (fbt), but other debugging/profiling code may benefit from it as well. I chose to make -mno-omit-leaf-frame-pointer not conditional on clang, because with gcc it is just a nop (i.e. it doesn't hurt anything). The patch looks good to me, please commit. ___ 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(2) while accept(2) is blocked
On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney j...@funkthat.com wrote: As someone else pointed out in this thread, if a userland program depends upon this behavior, it has a race condition in it... Thread 1 Thread 2Thread 3 enters routine to read enters routine to close calls close(3) open() returns 3 does read(3) for orignal fd How can the original threaded program ensure that thread 2 doesn't create a new fd in between? So even if you use a lock, this won't help, because as far as I know, there is no enter read and unlock mutex call yet... It is worse. Consider: fd = open(file,...); read(fd, ...); No guarantee read() gets data from the same opened file! Another thread could've come along, closed fd and pointed it to another file. So nothing is safe. Might as well stop using threads, right?! We are talking about cooperative threads where you don't have to assume the worst case. Here not being notified on a close event can complicate things. As an example, I have done something like this in the past: A frontend process validating TCP connections and then passing on valid TCP connections to another process for actual service (via sendmsg() over a unix domain). All the worker threads in service process can do a recvmsg() on the same fd. They process whatever tcp connection they get. Now what happens when the frontend process is restarted for some reason? All the worker threads need to eventually reconnect to a new unix domain posted by the new frontend process. You can handle this multiple ways but terminating all the blocking syscalls on the now invalid fd is the simplest solution from a user perspective. I decided long ago that this is only solvable by proper use of locking and ensuring that if you call close (the syscall), that you do not have any other thread that may use the fd. It's the close routine's (not syscall) function to make sure it locks out other threads and all other are out of the code path that will use the fd before it calls close.. If you lock before close(), you have to lock before every other syscall on that fd. That complicates userland coding and slows down things when this can be handled more simply in the kernel. Another usecase is where N worker threads all accept() on the same fd. Single threading using a lock defeats any performance gain. If someone could describe how this new eject a person from read could be done in a race safe way, then I'd say go ahead w/ it... Otherwise we're just moving the race around, and letting people think that they have solved the problem when they haven't... In general it just makes sense to notify everyone waiting on something that the situation has changed and they are going to have to wait forever. The kernel should already have the necessary information about which threads are sleeping on a fd. Wake them all up. On being awakened they see that the fd is no longer valid and all return with a count of data already read or -1 and EBADF. Doing the equivalent in userland is complicated. Carl has pointed out how BSD and Linux have required a workaround compared to Solaris and OS X (in Java and IIRC, the Go runtime). Seems like we have a number of usecases and this is something worth fixing. ___ 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
extattr_set_* return type
Despite the man page correctly describing the return value for extattr_set_*, I thought recently that they returned 0/-1 for success/failure, not the number of bytes written, like write(2). This is because extattr_set_* is declared as returning an int, not an ssize_t. Both extattr_get and extattr_list return ssize_t, so this is inconsistent. The patch at http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix-rmextattr-8-.patchfixes this. It compiles but it's untested. I don't think any compat shims are needed, since an old application will still sign extend and this will work (it's very unlikely anyone does extattr_set for 2GB or more). If anyone actually uses extattr on 64-bit, please test a new kernel but old userspace to be sure nothing is broken. I plan to commit this next week if I don't hear otherwise. Thanks, 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
how to force all packets to be ipv4 not v6
I have a host that for ISP reasons must have a ipv6 addr as well as the ipv4 but the ISP does not offer external ipv6 routing but all the commanes (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there anyway to force them to always use 4? ___ 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 force all packets to be ipv4 not v6
freebsd-net@ might have been a better choice, but... On Sun, Mar 31, 2013 at 01:20:17AM -0400, Aryeh Friedman wrote: I have a host that for ISP reasons must have a ipv6 addr as well as the ipv4 but the ISP does not offer external ipv6 routing but all the commanes (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there anyway to force them to always use 4? Which version of FreeBSD? See rc.conf(5) for 'ip6addrctl_policy'; I think this is what you're looking for. Glen pgp6JjfIxJ24R.pgp Description: PGP signature
Re: how to force all packets to be ipv4 not v6
On Sun, Mar 31, 2013 at 1:37 AM, Glen Barber g...@freebsd.org wrote: freebsd-net@ might have been a better choice, but... On Sun, Mar 31, 2013 at 01:20:17AM -0400, Aryeh Friedman wrote: I have a host that for ISP reasons must have a ipv6 addr as well as the ipv4 but the ISP does not offer external ipv6 routing but all the commanes (ssh, ftp, etc.) default to ipv6 and need special options to use 4 is there anyway to force them to always use 4? Which version of FreeBSD? 9.1 See rc.conf(5) for 'ip6addrctl_policy'; I think this is what you're looking for. Glen ___ 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
