[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: Xen cdrom haldaemon
Could the haldaemon's work be pushed into blkback in the kernel? -- Keir On 5/9/07 17:43, "Pat Campbell" <plc@xxxxxxxxxx> wrote: > Hi, > > I have found that the DOM0 CDROM device returns a stale disk > size if a CD is changed while any application has the device open. > > Test scenerio: ( Don't need XEN for this ) > Two shell processes > Shell A runs simple test program with an arg to > open the cd for reading > report media size using lseek(0, SEEK_END) > then enter a sleep loop leaving FD open > In Shell B > eject > insert a different CD > eject -t, > run simple test progran, no arg > ( size is still what was reported in shell A) > Kill Shell A test CD process > Run test CD process again, now you should have the > correct size > > Simple test program, cdrom-test.c, has been attached. > > I did enter a defect against the Linux kernel about this but > was unable to convince them it was their defect. > > If we put Xen in the mix, say installing a FV Redhat system > from physical CD media you will have two CDROM device file > descriptors open. One in blkback and the other in QEMU. > When you get to CD #2 you won't be able to complete the > install as the total disk size has not been updated for > the larger CD #2, stays at the smaller CD #1 size. > > You can get the QEMU descriptor closed by using xen-store > writes but none effect the blkback FD and there is no > way, that I have found, to effect ALL open Xen related FDs on > that device. > > I have created a proof of concept patch for 3.1 that addresses the > above issue by causing all VMs, FV and PV, to close thier open > pyhsical CDROM file descriptors when the device door is opened. File > descriptors are re-opened when the door is closed AND a CD was > inserted. > > The basic flow of the patch is: > > Kernel: > blkback driver: > if block device is a physical cdrom then > Add media_present=1 into xenstore backend/vbd > for this device > Place a xenstore watch on media_present > > watch_handler > if watch token is media_present > read value > if 0 then close block device fd > if 1 then re-open block device fd > > Any access with fd closed results in EACCESS error > > qemu > if block device is a cdrom > Place a xenstore watch on media_present > watch_handler > if watch token is media_present > read value > if 0 then close block device > if 1 then re-open block device and set media_changed > > Any access with fd closed results in EACCESS error > > xend > Starts XEN HalDaemon process > > XEN HalDaemon > Registers event callback for HALD events > callback handler > gets device major/minor numbers > for each vbd in xenstore > if matching major and minor > if add_event ( cdrom door closed with media ) > xenstore write 1 to vbd/media_present > else ( cddrom door open ) > xenstore write 0 to vbd/media_present > > I am just learning python, could use a python guy to enhance and > generalize. > > With my patch applied I was able to install RHEL5 from the 5 CD set as > well as a WIN2003 server from multi CD media. > > The patch is attached. Patch still needs some work but I would like > some feedback before going further down this path. Is this something > that fits into the current and near future architecture and might be > considered for addition? > > Thanks in advance > > Pat > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |