Re: VMWARE GSX Port?
-CURRENT runs on 3.0 as a domU. There is partial dom0 support. The changes have not gone back into the mainline because xenbus is extremely difficult to integrate cleanly. You can check on the state of the xen3 branch in perforce. -Kip On 3/2/06, Ashok Shrestha <[EMAIL PROTECTED]> wrote: > According to the Xen website, it's been ported to FreeBSD > [http://wiki.xensource.com/xenwiki/OSCompatibility]. > > Anybody know where port is? > > -Ashok Shrestha > > > On 2/28/06, Seán C. Farley <[EMAIL PROTECTED]> wrote: > > On Tue, 28 Feb 2006, Mike Silbersack wrote: > > > > > On Sat, 25 Feb 2006, Scott Long wrote: > > > > > >> Ashok Shrestha wrote: > > >>> VMWARE GSX was released recently for free. > > >>> [http://www.vmware.com/news/releases/server_beta.html] > > >>> > > >>> Is anyone working on a port for this? > > >> > > >> I've started on it, but I haven't made much progress yet. > > > > > > Anyone who's interested in working on it should make sure to start > > > with the VMWare 3 port (which works at present), and Orlando's beta > > > 4.5 port: > > > > > > http://www.break.net/orlando/freebsd.html > > > > Also, check out Wietse Venema's changes[1] done on top of Orlando's > > work. > > > > Seán > > 1. > > http://lists.freebsd.org/pipermail/freebsd-emulation/2006-February/001843.html > > -- > > [EMAIL PROTECTED] > > > > > -- > Ashok Shrestha > ___ > 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: VMWARE GSX Port?
According to the Xen website, it's been ported to FreeBSD [http://wiki.xensource.com/xenwiki/OSCompatibility]. Anybody know where port is? -Ashok Shrestha On 2/28/06, Seán C. Farley <[EMAIL PROTECTED]> wrote: > On Tue, 28 Feb 2006, Mike Silbersack wrote: > > > On Sat, 25 Feb 2006, Scott Long wrote: > > > >> Ashok Shrestha wrote: > >>> VMWARE GSX was released recently for free. > >>> [http://www.vmware.com/news/releases/server_beta.html] > >>> > >>> Is anyone working on a port for this? > >> > >> I've started on it, but I haven't made much progress yet. > > > > Anyone who's interested in working on it should make sure to start > > with the VMWare 3 port (which works at present), and Orlando's beta > > 4.5 port: > > > > http://www.break.net/orlando/freebsd.html > > Also, check out Wietse Venema's changes[1] done on top of Orlando's > work. > > Seán > 1. > http://lists.freebsd.org/pipermail/freebsd-emulation/2006-February/001843.html > -- > [EMAIL PROTECTED] > -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Accessing address space of a process through kld!!
alc (Alan Cox) is ill at the moment so may not be responding. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: unversal watchdog
On Wed, Mar 01, 2006 at 10:20:03PM -0700, M. Warner Losh wrote: > : You can do it with /etc/ttys. Actually this point is missing by many > : FreeBSD administrators, people just think of /etc/ttys in term of > : terminals and stuff :) But if youi'll open the man page you would > : found the following: It may have already been volunteered already; has the OP explored daemontools? I'll note that its master 'svscan' script is launched by an rc.d script (a decision of the port maintainer), not init directly, but that's not a hard change to affect... > Warner -- Brian Reichert <[EMAIL PROTECTED]> 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vn_lock(9)' LK_UPGRADE|LK_RETRY safety
Assume that thread owns LK_SHARED lock on vnode vp, and the call vn_lock(vp, LK_UPGRADE|LK_RETRY, curthread) is made. Is this upgrade safe from dropping shared lock during the retries made in vn_lock ? Man page for lockmgr says that failed LK_UPGRADE request returns with shared lock dropped. But, from the review of the code for lockmgr() and esp. acquire(), it seems that it is impossible to get error (due to absence of LK_NOWAIT and empty flags & zero timeout for msleep). Consequently, it seems that shared lock will not be dropped. Is this true ? Anyway, for instance, lookup(9) (sys/kern/vfs_lookup.c, line 552, rev. 1.88) uses such call and does not check for errors. Best regards, Kostik Belousov pgp99H52qApj8.pgp Description: PGP signature
Re: Accessing address space of a process through kld!!
On Wed, Mar 01, 2006 at 10:54:49AM -0500, John Baldwin wrote: > > I have two questions about this function: > > > > 1. vm_fault() does not guarantee, that (possibly) faulted in page > > will be in the object or in one of backing objects when > > vm_fault() returns, because a page can become not resident > > again. Why not to wire needed page in vm_fault() (by giving > > a special flag to vm_fault() function)? > > > > 2. When the object which owns the page is unlocked, which lock > > guarantees, then m will point to a page? I mean m, which is > > used in vm_page_hold(m), which is called after VM_OBJECT_UNLOCK() > > (I mean a gap of time between VM_OBJECT_UNLOCK() and > > vm_page_lock_queues() function calls). > > > > Can you answer these two question? Thanks. > > Those are outside of my realm of knowledge unfortunately, but there are > some other folks you can ask including probably truckman@ and [EMAIL > PROTECTED] I'll wait some time for answers and may be will ask them directly in a private mail. Probably I need to create situation to force proc_rwmem() to make possibly incorrect step. Less than one year ago I found several bugs in FreeBSD VM subsystem (I found that bugs from theoretical understanding how everything works). Then I wrote userland programs to simulate that bugs. With one test program VM simply incorrectly worked and with another test program VM panics. I sent two comments about this to hackers@ mailing list, but haven't received any response (I just asked to give more strict description of VM semantics). (in groups.google.com type "wired shared comments freebsd" and see two comment in the top of the search results) I see similar problems (?) as I described above in another parts of the system. For example vfs_export.c:vfs_export_lookup() function references np after releasing lock on head of corresponding PATRICIA tree: RADIX_NODE_HEAD_LOCK(rnh); np = (struct netcred *) (*rnh->rnh_matchaddr)(saddr, rnh); RADIX_NODE_HEAD_UNLOCK(rnh); if (np && np->netc_rnodes->rn_flags & RNF_ROOT) np = NULL; Also references to heads of PATRICIA trees are not protected by any lock. I think that everything works, because there is another mutex which protects these structures. For example Giant is acquired in nfs_srvsubs.c:nfsrv_fhtovp() before calling VFS_CHECKEXP and it is also acquired at some point in mount() path and lock on it occasionally is not lost in another function, for example in msleep(). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
