Re: valgrind on FreeBSD 7
On Tue, 18 Mar 2008, Mike Silbersack wrote: > Here's a tarball of what's in perforce right now. I tried it a > little bit, and it seemed to work for me. Make sure to install the > kernel module! > > http://www.silby.com/valgrind_freebsd_3.tar.gz > > But don't send me questions about it - I'm not an expert on it, I'm > just the guy who grabbed it from perforce and found that it seems to > work. :) Thanks for that (and to whomever is cutting the code)! Valgrind is an enormously helpful tool. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: valgrind on FreeBSD 7
On Mon, 17 Mar 2008, Heiko Wundram wrote: Hey all! It's been some time now, and I just wanted to ping quietly whether there's any chance to get (a preview of) the valgrind adapted for FreeBSD 7. out is a futile task, I guess, as I didn't manage to find it in the FreeBSD perforce repository the last time I looked (and was pointed there), but that's probably due to my personal stupidity in using the web-frontend for Perforce (which I find absolutely horrible). Thanks for any pointer/hint/message! -- Heiko Wundram Here's a tarball of what's in perforce right now. I tried it a little bit, and it seemed to work for me. Make sure to install the kernel module! http://www.silby.com/valgrind_freebsd_3.tar.gz But don't send me questions about it - I'm not an expert on it, I'm just the guy who grabbed it from perforce and found that it seems to work. :) -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
remote operation or admin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have 4 computers, 1 big FreeBSD-current (4 x86 procs), 2 GentooLinux (1 is a dial AMD Opteron, the other a dual older x86), and 1 MacOSX (dual PPC). I was thinking about looking for two items, I'm not sure if I want one or both of them: either some software to let me merely remotely manage them (public software, mind) or, even better, something to get these disparate hardwares to be able to work together, and (as much as possible) to be able to share work. What might be the best, in terms of ability, and especially the ability to make these work together? If they're not a FreeBSD port, as long as they're reasonably stable, I don't mind porting things, but it needs to be stable on all those CPUs. Could you reo\commend me something? I'll go chase each one down, I won't jump on you if you're wrong, gimme your guesses, ok? Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3xBFz62J6PPcoOkRAoTnAJ9YmcaNg54AF8Gz7MN+DO5KZKdVzACfcOoM tys5V3b/kiN1+nzDGhtv7Lk= =YAXx -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Summer of Code 2008 Project Ideas
On 17/03/2008, Murray Stokely <[EMAIL PROTECTED]> wrote: > The FreeBSD Project was again accepted as a mentoring organization for > the Google Summer of Code. The student application period will begin > next week so if you have any ideas for great student projects, please > send them to [EMAIL PROTECTED] or post them here for discussion. [snip] How about tick()-less kernel - replace dependance on regular hearbeat with a delta-queue that could be used to program the time of the next scheduled interrupt? You could start with the delta-queue pretending to be a regular heart beat then work on changing deltas between events... I'm sure there was a mention of something similar in Linux... Cheers, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Summer of Code 2008 Project Ideas
The FreeBSD Project was again accepted as a mentoring organization for the Google Summer of Code. The student application period will begin next week so if you have any ideas for great student projects, please send them to [EMAIL PROTECTED] or post them here for discussion. A good student project has a well defined purpose, some key FreeBSD developers that could be identified as potential mentors, and is feasible for a student to complete in a few months time. The existing ideas list is available here : http://www.freebsd.org/projects/ideas/ If you can suggest something (getting specific parts of valgrind working on FreeBSD?) then please provide information in the form of the other projects listed on the page as far as difficulty level, requirements, etc.. Thanks, - Murray ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Summer of Code 2008 Project Ideas
The FreeBSD Project was again accepted as a mentoring organization for the Google Summer of Code. The student application period will begin next week so if you have any ideas for great student projects, please send them to [EMAIL PROTECTED] or post them here for discussion. A good student project has a well defined purpose, some key FreeBSD developers that could be identified as potential mentors, and is feasible for a student to complete in a few months time. The existing ideas list is available here : http://www.freebsd.org/projects/ideas/ If you can suggest something (getting specific parts of valgrind working on FreeBSD?) then please provide information in the form of the other projects listed on the page as far as difficulty level, requirements, etc.. Thanks, - Murray ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[4]: vkernel & GSoC, some questions
: :Matt, : :You sure won't argue that UML isolation is inherently better than one that can be provided by a hypervisor. If the performance is the same, what are you gaining? : :Hypervisor while slow, allows treating a complete OS with all applications as a black box. Why would I choose UML over a hypervisor? : :I am not trying to say there cannot be a place for vkernel. [I don't even yet understand what is does or how.] However, as a hosting company, why would I choose UML over a hypervisor? : :... : :igor Well, whos hypervisor are you using? -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
:> In all three cases the emulated hardware -- disk and network basically, :> devolves down into calling read() or write() or the real-kernel :> equivalent. A hypervisor has the most work to do since it is trying to :> emulate a hardware interface (adding another layer). XEN has less work :> to do as it is really not trying to emulate hardware. A vkernel has :> even less work to do because it is running as a userland program and can :> simply make the appropriate system call to implement the back-end. : :And jails and similar have the absolute minimum.. :at the cost of making a single accessible point of failure :(the one kernel). Yes, absolutely. Jails have the greatest performance, though the characterization of a single point of failure is a bit misleading. The problem with a jail is that all programs running under it are directly accessing the real kernel and are able to exercise *ALL* code paths into that kernel, even many root code paths, and thus expose all the bugs in that kernel. A vkernel or hypervisor use only a subset of the real kernel's functionality resulting in much lower exposure to potential kernel bugs. While a vkernel or kernel running under a hypervisor is fully exposed, a failure of same does not cause the whole machine to fail and a recovery 'reboot' can be as short as 5 seconds. The cost is performance. Even if you were to instrument the kernel code with full resource control (jailed memory use, I/O, descriptors, real-kernel memory use, etc)... even if you were to do that, it still doesn't solve the bug exposure issue. In anycase, there are only two performance bottlenecks that really matter for a vkernel or hypervisor: (1) system calls from virtualized processes to their virtualized kernels, and (2) MMU invalid page faults. The I/O path is a distant third, really requiring only a co-thread or two for write()s to be made efficient. (1) and (2) are not easy problems to solve, mainly due to the need for the real kernel to have exclusive access to the context when doing an iret (a R/W shared mapping of the top of the kernel stack is a security hole). I do think a read-only mapping might be doable, particularly for the standard syscall path which only modifies EAX and EDX in the critical path. That would cut the overhead in half. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
Matthew Dillon wrote: I guess my problem is that you are holding this up as a red flag when it isn't even remotely close to being one. What I have said is that the dragonfly vkernel work is the interesting beginning of a project, but that further work needs to be done before the project is finished in the sense of having reasonable performance, and anyone approaching a FreeBSD port needs to be aware of the scope of the work needed. If you feel that is "belittling" you, then I'll have to beg your indulgence for not also donning a miniskirt and pompoms. Now that's an image I bet you all weren't expecting. Hah! :-D Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
Kris Kennaway wrote: Matthew Dillon wrote: :I don't think there's an issue that needs solving, GCC has -nostdlib and :-fno-builtin for precisely this reason. You are missing the point entirely. The point is to allow the vkernel to use libc, aka allow it to be compiled, linked, and run as a normal user process. What is your rationale for trying to bypass libc? Why is it so important to you that the kernel retain all those conflicting symbols when it takes literally just an hour of work to fix all the conflicts? If your goal is to link vkernels with libc then by definition you are forced to resolve the namespace conflicts, but I don't see this as a necessary goal. A minimal standalone libkernel would do the same thing without requiring global changes to the kernel namespace, which would likely cause a lot of downstream angst for users of FreeBSD kernel code, providers of third party modules, etc. It seems pretty hard to justify that level of disruption. It should be possible to make a libemul that provides just eh services needed, by doing the syscall() operation. actually, here's an idea.. a separate interpreter/exec/loader class that embeds some of the work into the kernel and uses syscalls that are designed exactly for the job required. (loaded as a .ko when needed.). who says it needs to run posix syscalls...? :Anyway, I agree that this is the least of someone's worries during a :hypothetical port of the dragonfly vkernel code. Just so everyone is :clear, the scope of such an effort would not be "port the code", it :would be "port the code and also finish it". : :Kris Jeeze, you make it sound like it is some incomplete mess when it is far, far from that. The vkernel is complete, the APIs are complete. It isn't finished in the sense that certain aspects of it, primarily the 'disk' emulation, is not very well optimized, but you are doing the work an extreme disservice by belittling it with undeserving labels. What is the undeserving label? You agree that the code is not finished. In your previous emails you yourself gave a long discussion of changes that would need to be made to bring reasonable performance to various aspects of the vkernel code. I am not discouraging anyone from contributing to that work either in the context of the FreeBSD project or the Dragonfly project; on the contrary we are both pointing out that there is work that needs to be done by someone. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
: :If your goal is to link vkernels with libc then by definition you are :forced to resolve the namespace conflicts, but I don't see this as a :necessary goal. A minimal standalone libkernel would do the same thing :without requiring global changes to the kernel namespace, which would :likely cause a lot of downstream angst for users of FreeBSD kernel code, :providers of third party modules, etc. It seems pretty hard to justify :that level of disruption. Uh, well, each to his own but it sounds like pretty flimsy reasoning considering that major changes are made to the FreeBSD kernel every few months, particularly as related to APIs. Frankly, adding a 'k' is not a big deal and holding up opaque third party modules as a reason for not evolving the system is pretty damn stupid considering the poor track record opaque black boxes have with regards to keeping up-to-date with open source software generally. If they are driving the FreeBSD development process then you have a serious problem on your hands that goes beyond renaming a few functions. We had more issues changing the mbuf M_ defines to MB_ then we ever had changing the kernel printf to kprintf. Not the least of which being that any issue that crops up due to a namespace change is immediately apparent simply due to the kernel failing to link or a module failing to load. In a word: It's not the big deal you are making it out to be. In anycase, there is a lot more to running a UML/vkernel then just calling read() or write(). You only have to browse the platform/vkernel code to see all the places where there is a very high convenience factor to not having to hack around libc. Your statement about using libkernel is short-sighted. :What is the undeserving label? You agree that the code is not finished. : In your previous emails you yourself gave a long discussion of changes :that would need to be made to bring reasonable performance to various :aspects of the vkernel code. I am not discouraging anyone from :contributing to that work either in the context of the FreeBSD project :or the Dragonfly project; on the contrary we are both pointing out that :there is work that needs to be done by someone. : :Kris I'm a perfectionist. No code is ever finished for me. 'Optimal' for someone like me is counting machine cycles and worrying about cache footprints, it's not the same definition that most other people use. I guess my problem is that you are holding this up as a red flag when it isn't even remotely close to being one. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
valgrind on FreeBSD 7
Hey all! It's been some time now, and I just wanted to ping quietly whether there's any chance to get (a preview of) the valgrind adapted for FreeBSD 7. I'm currently hitting a point in my development where compiling the code on Linux to run valgrind simply won't do anymore, because of code dependencies on FreeBSD (generally, the Bluetooth framework, which is completely different on Linux, and I'm not prepared to make the code portable just yet ;-)). I know there's work on getting valgrind to run on AMD64 (which should also be adapted for FreeBSD 7, I presume), but pointing me at Perforce to check it out is a futile task, I guess, as I didn't manage to find it in the FreeBSD perforce repository the last time I looked (and was pointed there), but that's probably due to my personal stupidity in using the web-frontend for Perforce (which I find absolutely horrible). Thanks for any pointer/hint/message! -- Heiko Wundram ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
Matthew Dillon wrote: In all three cases the emulated hardware -- disk and network basically, devolves down into calling read() or write() or the real-kernel equivalent. A hypervisor has the most work to do since it is trying to emulate a hardware interface (adding another layer). XEN has less work to do as it is really not trying to emulate hardware. A vkernel has even less work to do because it is running as a userland program and can simply make the appropriate system call to implement the back-end. And jails and similar have the absolute minimum.. at the cost of making a single accessible point of failure (the one kernel). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
Matthew Dillon wrote: :I don't think there's an issue that needs solving, GCC has -nostdlib and :-fno-builtin for precisely this reason. You are missing the point entirely. The point is to allow the vkernel to use libc, aka allow it to be compiled, linked, and run as a normal user process. What is your rationale for trying to bypass libc? Why is it so important to you that the kernel retain all those conflicting symbols when it takes literally just an hour of work to fix all the conflicts? If your goal is to link vkernels with libc then by definition you are forced to resolve the namespace conflicts, but I don't see this as a necessary goal. A minimal standalone libkernel would do the same thing without requiring global changes to the kernel namespace, which would likely cause a lot of downstream angst for users of FreeBSD kernel code, providers of third party modules, etc. It seems pretty hard to justify that level of disruption. :Anyway, I agree that this is the least of someone's worries during a :hypothetical port of the dragonfly vkernel code. Just so everyone is :clear, the scope of such an effort would not be "port the code", it :would be "port the code and also finish it". : :Kris Jeeze, you make it sound like it is some incomplete mess when it is far, far from that. The vkernel is complete, the APIs are complete. It isn't finished in the sense that certain aspects of it, primarily the 'disk' emulation, is not very well optimized, but you are doing the work an extreme disservice by belittling it with undeserving labels. What is the undeserving label? You agree that the code is not finished. In your previous emails you yourself gave a long discussion of changes that would need to be made to bring reasonable performance to various aspects of the vkernel code. I am not discouraging anyone from contributing to that work either in the context of the FreeBSD project or the Dragonfly project; on the contrary we are both pointing out that there is work that needs to be done by someone. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[2]: vkernel & GSoC, some questions
Some interesting reading for anyone who cares: http://citeseer.ist.psu.edu/rd/89980079%2C480988%2C1%2C0.25%2CDownload/http://citeseer.ist.psu.edu/cache/papers/cs/24361/http:zSzzSzwww.usenix.orgzSzpublicationszSzlibraryzSzproceedingszSzusenix01zSzsugermanzSzsugerman.pdf/venkitachalam01virtualizing.pdf > These shortcuts are going to be considerably more efficient, resulting >in better performance. It is also the claim to fame that a vkernel >architecture has. In fact, XEN is really much closer to a vkernel >architecture then it is to a hypervisor architecture. A vkernel can >be thought of as the most generic and flexible implementation, with >access to many system calls verses the fairly limited set XEN provides, >and a hypervisor's access to the same subset is done by emulating >hardware devices. I've never used XEN (paravirtualization) but I assume that the target OS then has special system calls or shortcuts to ask the underlying monitor/hypervisor to the right things (like allocate safe (virtual) memory instead of relying on a shadow/trap model etc.). >In all three cases the emulated hardware -- disk and network basically, >devolves down into calling read() or write() or the real-kernel >equivalent. A hypervisor has the most work to do since it is trying to >emulate a hardware interface (adding another layer). XEN has less work >to do as it is really not trying to emulate hardware. A vkernel has >even less work to do because it is running as a userland program and can >simply make the appropriate system call to implement the back-end. I'm pretty sure this is what VMWare does for the their hosted product. Its a simple userland process that makes syscalls and traps interrupts which eventually devolve into reads and writes. I believe they do a lot of performance work in interrupt coalescing and doing their darnest to prevent world-wide context switches. > There are more similarities then differences. I expect VMWare is feeling >the pressure from having to hack their code so much to support multiple >operating systems... I mean, literally, every time microsoft comes out >with an update VMWare has to hack something new in. it's really amazing >how hard it is to emulate a complete hardware environment, let alone do >it efficiently. No doubt virtualization is a tough job and I'm wondering if future hardware enhancements will make software like VMWare/vkernel/XEN obsolete in the end. >Frankly, I would love to see something like VMWare force an industry-wide >API for machine access which bypasses the holy hell of a mess we have >with the BIOS, and see BIOSes then respec to a new far cleaner API. The >BIOS is the stinking pile of horseshit that has held back OS development >for the last 15 years. EFI? Just kidding... -aps -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
:I don't think there's an issue that needs solving, GCC has -nostdlib and :-fno-builtin for precisely this reason. You are missing the point entirely. The point is to allow the vkernel to use libc, aka allow it to be compiled, linked, and run as a normal user process. What is your rationale for trying to bypass libc? Why is it so important to you that the kernel retain all those conflicting symbols when it takes literally just an hour of work to fix all the conflicts? :Anyway, I agree that this is the least of someone's worries during a :hypothetical port of the dragonfly vkernel code. Just so everyone is :clear, the scope of such an effort would not be "port the code", it :would be "port the code and also finish it". : :Kris Jeeze, you make it sound like it is some incomplete mess when it is far, far from that. The vkernel is complete, the APIs are complete. It isn't finished in the sense that certain aspects of it, primarily the 'disk' emulation, is not very well optimized, but you are doing the work an extreme disservice by belittling it with undeserving labels. Do you think that hypervisors are magically more efficient? Do you honestly believe that having to spend thousands of man hours writing one hack after another to make windows run well on VMWare is the proper development path? Do you really want to load opaque black boxes into FreeBSD's kernel which you have no control over? If you have some disagreement about the APIs used to implement the emulation then I am all ears. Is there something you don't like about the new mmap() feature? Is there something you don't like about the new vmspace_*() system calls? I'm a perfectionist but my work output is also limited. You are quite welcome to help improve our projects, but if you are expecting me to dedicate my entire life to 'improving' one single aspect of our project, the vkernel in this case, just to satisfy some twisted idea of completeness, it isn't going to happen. Code submissions are always welcome in our corner of the woods. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[2]: vkernel & GSoC, some questions
:Matt, I'm sorry I'm not trying to hijack this thread but isn't the vkernel :approach very similar to VMWare's hosted architecture products (such as :Fusion for the Mac and Client Workstation for windows)? : :As I understand it, they have a regular process like vkernel called :vmware-vmx which provides the management of different VM contexts running :along side the host OS. It also does a passthrough for invalid PTEs to the :real kernel and manages contexts in I believe the same fashion you just :described. There is also an I/O subsystem a long side it to reuse the :hosted drivers to managed the virtualized filesystem and devices - not sure :what Dragon does. : :I realize that their claim to fame is as you said x86 binary code :translations but I believe VMWare's product is very close to what you are :describing with respect to vkernels (please correct me if I'm wrong). Its :just that this thread has devolved slightly into a hypervisor vs. hosted :architecture world and I believe their is room for both. : :Thanks! : :-aps This reminds me of XEN. Basically instead of trying to rewrite instructions or do 100% hardware emulation it sounds like they are providing XEN-like functionality where the target OS is aware it is running inside a hypervisor and can make explicit 'shortcut' calls to the hypervisor instead of attempting to access the resource via emulated hardware. These shortcuts are going to be considerably more efficient, resulting in better performance. It is also the claim to fame that a vkernel architecture has. In fact, XEN is really much closer to a vkernel architecture then it is to a hypervisor architecture. A vkernel can be thought of as the most generic and flexible implementation, with access to many system calls verses the fairly limited set XEN provides, and a hypervisor's access to the same subset is done by emulating hardware devices. In all three cases the emulated hardware -- disk and network basically, devolves down into calling read() or write() or the real-kernel equivalent. A hypervisor has the most work to do since it is trying to emulate a hardware interface (adding another layer). XEN has less work to do as it is really not trying to emulate hardware. A vkernel has even less work to do because it is running as a userland program and can simply make the appropriate system call to implement the back-end. There are more similarities then differences. I expect VMWare is feeling the pressure from having to hack their code so much to support multiple operating systems... I mean, literally, every time microsoft comes out with an update VMWare has to hack something new in. it's really amazing how hard it is to emulate a complete hardware environment, let alone do it efficiently. Frankly, I would love to see something like VMWare force an industry-wide API for machine access which bypasses the holy hell of a mess we have with the BIOS, and see BIOSes then respec to a new far cleaner API. The BIOS is the stinking pile of horseshit that has held back OS development for the last 15 years. For hardware emulation to really work efficiently one pretty much has to dedicate an entire cpu to the emulator in order to allow it to operate more like a coprocessor and save a larger chunk of the context switch overhead which is the bane of VMWare, UML/vkernel, AND XEN. This may seem wasteful but when you are talking about systems with 4 or more cores which are more I/O and memory limited then they are cpu limited, dedicating a whole cpu to handle critical path operations would probably boost performance considerably. -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
Maslan wrote: Hi all, Aren't we working on a FreeBSD/Xen port ??? I think we don't need a Linux like KVM or DragonFly's vkernel, if we could run FreeBSD in dom0. I agree that people interested in virtualization will get the most return on investment if they contribute to the Xen port, large amounts of which are complete. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
Matthew Dillon wrote: :> Well, I don't think I would agree with your assessment but, :> particularly, the way vkernels are implemented in DragonFly is NOT :> in the least disruptive to kernel source. : :I was referring to the decision you made to rename all of the kernel :functions that conflicted with libc functions so that vkernels could be :linked against libc. : :Kris Huh. Well, that's about the last thing I would have thought would be considered disruptive to the kernel source. I don't think there's an issue that needs solving, GCC has -nostdlib and -fno-builtin for precisely this reason. Anyway, I agree that this is the least of someone's worries during a hypothetical port of the dragonfly vkernel code. Just so everyone is clear, the scope of such an effort would not be "port the code", it would be "port the code and also finish it". Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re[2]: vkernel & GSoC, some questions
On Sun, Mar 16, 2008 at 7:13 PM, Matthew Dillon <[EMAIL PROTECTED]> wrote: >Basically DragonFly has a syscall API that allows a userland process >to create and completely control any number of VM spaces, including >the ability to pass execution control to a VM space and get it back, >and control memory mappings within that VM space (and in the virtual >kernel process itself) on a page-by-page basis, so only 'invalid' PTEs >are passed through to the virtual kernel by the real kernel and the >real kernel caches page mappings with real hardware pmaps. Any >exception that occurs within a running VM space is routed back to the >virtual kernel process by the real kernel. Any real signal (e.g. the >vkernel's 'clock' interrupt) or exception that occurs also forces > control >to return to the vkernel process. Matt, I'm sorry I'm not trying to hijack this thread but isn't the vkernel approach very similar to VMWare's hosted architecture products (such as Fusion for the Mac and Client Workstation for windows)? As I understand it, they have a regular process like vkernel called vmware-vmx which provides the management of different VM contexts running along side the host OS. It also does a passthrough for invalid PTEs to the real kernel and manages contexts in I believe the same fashion you just described. There is also an I/O subsystem a long side it to reuse the hosted drivers to managed the virtualized filesystem and devices - not sure what Dragon does. I realize that their claim to fame is as you said x86 binary code translations but I believe VMWare's product is very close to what you are describing with respect to vkernels (please correct me if I'm wrong). Its just that this thread has devolved slightly into a hypervisor vs. hosted architecture world and I believe their is room for both. Thanks! -aps -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OpenBSD sdiff Question
On Mar 15, 2008, at 23:29 , David O'Brien wrote: On Sat, Mar 15, 2008 at 03:21:01PM -0700, Bert JW Regeer wrote: Even if BSD has no tradition to keep a separate program version, it is still very handy to be able to give this data to other developers if something is failing. $ ident failing-binary is the output that means something. A version string will not. Programs that don't have a -v or --version switch are frustrating to Anyone used to working on BSD will not expect a -v switch. It isn't part of BSD tradition. The simple fact there is no obivous "version" to print just shows that in a OS that is developed and built as a whole, having a version on the util is meaningless. Dropping -v would be a bad thing, and make the tools not compatible, thus breaking many scripts that do expect a -v. Come on, how many scripts do you write that do "sdiff -v" today? -- -- David ([EMAIL PROTECTED]) I see the reasoning behind dropping it now. It certainly make sense as you and Peter Jeremy describe it, I have just never thought of it that way. Cheers, Bert JW Regeer
Re: vkernel & GSoC, some questions
:> Well, I don't think I would agree with your assessment but, :> particularly, the way vkernels are implemented in DragonFly is NOT :> in the least disruptive to kernel source. : :I was referring to the decision you made to rename all of the kernel :functions that conflicted with libc functions so that vkernels could be :linked against libc. : :Kris Huh. Well, that's about the last thing I would have thought would be considered disruptive to the kernel source. Everyone liked those changes. malloc -> kmalloc, printf -> kprintf, and so forth... just not a big deal and it allowed numerous special cases in the header files dealing with prototype conflicts to be removed in addition to allowing vkernel's to link against libc. Not only that but it removed conflicts against GCC builtins (which have their own ideas about what '%' features are valid and what are not) and properly separated kernel functions like sprintf to ksprintf, especially considering that the kernel version of sprintf does not support everything that the libc version does. For that matter you might as well throw in the system call function name changes. Instead of the actual system call in the kernel being called 'read()' it is now called 'sys_read()', so as not to conflict with 'read()'. That turned out to be a major positive clarification of the source code that made syscall entry points completely obvious to even non kernel programmers trying to read and understand it. All in all, it was a very good move for the project and I would strongly recommend that FreeBSD do the same thing. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vkernel & GSoC, some questions
Hi all, Aren't we working on a FreeBSD/Xen port ??? I think we don't need a Linux like KVM or DragonFly's vkernel, if we could run FreeBSD in dom0. Thank a lot On Mon, Mar 17, 2008 at 3:09 AM, Kip Macy <[EMAIL PROTECTED]> wrote: > On Sun, Mar 16, 2008 at 8:06 PM, Adrian Chadd <[EMAIL PROTECTED]> wrote: > > On 16/03/2008, Robert Watson <[EMAIL PROTECTED]> wrote: > > > > > Another avenue to consider is the Linux KVM virtualization technology, > which > > > is seeing a high level of interest in the Linux community and sounds > > > increasingly mature and well-exercised. It would also offer > interesting > > > migration benefits for Linux users wanting to try FreeBSD, allowing > them to > > > trivially create new FreeBSD installs under their existing Linux > install. We > > > had an SoC project last year but I'm not sure what the outcome was; it > would > > > be useful to give Fabio a ping and see how things are going. > Obviously, > > > anyone doing this project would need to manage the license issues > involved > > > carefully. > > > > Wasn't part of the original KVM idea to support a "hypervisor" > > interface to a parent, sort of Xen-like, providing interrupt, VM and > > inter-VM "IPC" hooks? > > > > I remember seeing this stuff a while back but for some reason all I > > read about KVM - outside of what Redhat are doing with it and Xen now > > - focuses on hardware virtualisation. > > > > A BSD-licenced KVM hypervisor + FreeBSD kernel might be an interesting > > project. I'm pretty sure Rusty wrote a very very lightweight KVM > > hypervisor as a demonstration which may serve as a starting point for > > things. > > > Nope. It is called lguest, is GPL, IBM has the rights to it and has no > interest in changing the license. > > Using KVM for architectural ideas while starting from a fresh codebase > is really the only way to go if you are concerned with licensing. > > -Kip > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 7.0 on ASUS P4R8L - No Disks Found!
I suppose this should go to [EMAIL PROTECTED] But with that said, what mode is your SATA/IDE controller in? If there is an AHCI or Legacy mode, try it again. -aps On Mon, Mar 17, 2008 at 12:42 AM, Eddie Parra <[EMAIL PROTECTED]> wrote: > (Newbie) I have FreeBSD 6.3 working on my Asus AB-2800. I just attempted > a > fresh install of 7.0 and it couldn't find my disks - "No Disks Found!" > The > Motherboard Chipset is ATI RS300 / IXP200. Any suggestions would > be appreciated. Thanks! > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OpenBSD sdiff Question
In the last episode (Mar 17), Steven Kreuzer said: > On Sat, Mar 15, 2008 at 11:29:19PM -0700, David O'Brien wrote: > > On Sat, Mar 15, 2008 at 03:21:01PM -0700, Bert JW Regeer wrote: > > > Even if BSD has no tradition to keep a separate program version, it is > > > still very handy to be able to give this data to other developers if > > > something is failing. > > > > $ ident failing-binary is the output that means something. A version > > string will not. > > > > > > > Programs that don't have a -v or --version switch are frustrating to > > > > Anyone used to working on BSD will not expect a -v switch. It > > isn't part of BSD tradition. The simple fact there is no obivous > > "version" to print just shows that in a OS that is developed and > > built as a whole, having a version on the util is meaningless. > > > > > Dropping -v would be a bad thing, and make the tools not > > > compatible, thus breaking many scripts that do expect a -v. > > > > Come on, how many scripts do you write that do "sdiff -v" today? > > I have to agree with this. > > I will submit the port without -v/--version > and worse comes to worse, add it in later if enough people complain. On the other hand, some programs that are contributed sources or are developed outside the FreeBSD cvs tree do have versions of their own. awk and tar, for example both recognize the --version flag (but not -v since that is already used). -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OpenBSD sdiff Question
On Sat, Mar 15, 2008 at 11:29:19PM -0700, David O'Brien wrote: > On Sat, Mar 15, 2008 at 03:21:01PM -0700, Bert JW Regeer wrote: > > Even if BSD has no tradition to keep a separate program version, it is > > still very handy to be able to give this data to other developers if > > something is failing. > > $ ident failing-binary is the output that means something. A version > string will not. > > > > Programs that don't have a -v or --version switch are frustrating to > > Anyone used to working on BSD will not expect a -v switch. It isn't part > of BSD tradition. The simple fact there is no obivous "version" to print > just shows that in a OS that is developed and built as a whole, having a > version on the util is meaningless. > > > Dropping -v would be a bad thing, and make the tools not compatible, > > thus breaking many scripts that do expect a -v. > > Come on, how many scripts do you write that do "sdiff -v" today? I have to agree with this. I will submit the port without -v/--version and worse comes to worse, add it in later if enough people complain. -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Failure to Project OOImpress
On 3/15/08, KAYVEN RIESE <[EMAIL PROTECTED]> wrote: > On Sat, 15 Mar 2008, Paul B. Mahol wrote: > > > Was it connected prior or after Xorg startup? > > I think we connected prior. Should we have? I had my > computer turned off, and I booted it up. The projector > was on during boot. I thought the boot process would > take care of it but it didn't. > It should not be directly related to system in any way. Googling around, I found that Xorg resolutions and modelines must be configured for projectors in the same way as with second monitors ie creating another display or screen layout in xorg.conf. But is should work "out of box way" if for example projector/monitor support current Xorg resolution. Also there are some problems (found by googling) with gdm and projectors in linux environment (no reasons why it should not happen in freebsd also). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Review please: pfil FIRST/LAST
On Monday 17 March 2008 11:29:15 Vadim Goncharov wrote: > On Sun, 16 Mar 2008 00:05:36 +0100; Max Laier wrote about 'Review please: pfil FIRST/LAST': > > attached is a small diff to allow pfil(9) consumers to force a > > sticky position on the head/tail of the processing queue. This > > can be used to do traffic conditioning kind of tasks w/o > > disturbing the other filters. I will need this to implement > > carp(4) ip based load balancing. While here I also removed a few > > paragraphs in BUGS which are no longer true (since we are using > > rmlocks for pfil(9)). > > > > I'd appreciate review of the logic in pfil_list_add - just to make > > sure I didn't botch it. Thanks. > > Could it be done a way which will allow user a simple configuration of > filter plly ordering? E.g. to specify that order must alway be "ipfw, > then pf". This is a separate issue. I had patches once to specify hook order via sysctl and will probably revisit this as I like the idea. For now, though, this is not what I'm interested in. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Review please: pfil FIRST/LAST
Hi Max Laier! On Sun, 16 Mar 2008 00:05:36 +0100; Max Laier wrote about 'Review please: pfil FIRST/LAST': > attached is a small diff to allow pfil(9) consumers to force a sticky=20 > position on the head/tail of the processing queue. This can be used to=20 > do traffic conditioning kind of tasks w/o disturbing the other filters. =20 > I will need this to implement carp(4) ip based load balancing. While=20 > here I also removed a few paragraphs in BUGS which are no longer true=20 > (since we are using rmlocks for pfil(9)). > I'd appreciate review of the logic in pfil_list_add - just to make sure I=20 > didn't botch it. Thanks. Could it be done a way which will allow user a simple configuration of filter plly ordering? E.g. to specify that order must alway be "ipfw, then pf". -- WBR, Vadim Goncharov. ICQ#166852181 mailto:[EMAIL PROTECTED] [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
