From: James M. <jam...@ho...> - 2002-10-02 06:31:57
Attachments:
build.txt
|
This updates ARCH_SUBDIRS to have the missing trailing / so it can be added to core-y directly and gets rid of the old link.ld references. ARCH_SUBDIRS is used in the for loops in the Makefile to clean up. It also drops the core-y from Makefile-os-Linux since this is already included from the arch/um/Makefile anyway and produced errors during build. Do you want to get rid of the Makefile-os-Linux? or maybe the references in Makefile It puts in the user_syms.o that keeps escaping from arch/um/kernel/Makefile which is seen as bad depmod/link problems with the standard library funcitions. |
From: James M. <jam...@ho...> - 2002-10-02 06:32:46
Attachments:
mounts.txt
|
Here are the rejected do_mounts changes that Linus does not want but that are really needed for ease of use in UML. I would suggest that until the proper fix goes in (after Al Viro gets done changing the interface) putting this in the uml-patch-2.5.XX-Y for use by UMLers as it is hard to explain root=0x6211 clearly enough, and I get it wrong with too high a frequency myself. I admit it is ugly but so is every other boot method in do_mounts, ide, scsi, the special cases for net boot. This could just stay in the uml tree until something better is available, but without the ugly version and without the new it is left with only numeric root devices :( |
From: James M. <jam...@ho...> - 2002-10-02 06:32:34
Attachments:
ubd.txt
|
Here is a patch for just ubd_kern.c & ubd_user.h it has the cleanups (C99 initializers etc) and partition stuff. ubd_user.h has the shift instead of doing the two 64 divides, under most gcc optimization levels it is both smaller and faster. I had originally put it in as a clean up some months ago and pulled it back in while trying to get the 2.5.39 linking working correctly as it gets rid of some of the _mul64/_div64 from the gcc compiler libraries that are not normally linked into a linux kernel but that was not enough to get me going so my previous patch had changes at the top level make file :( yours is better :) I have sent most of this in various patches before, though it still may have glitches it worked for me. This patch is against vanilla 2.5.39 + your uml-patch-2.5.39 I booted with ubdb=COW1,fnark.img root=/dev/ubdb1 and it came up ok. |
From: James M. <jam...@ho...> - 2002-10-10 17:34:56
Attachments:
diff-2.5.41-1
|
Ok, here is the partition patch updated to uml-patch-2.5.41-1 It has a couple more C99 updates I made the local structs in the ioctl, local to the individual ioctl-subfunctions Iff the devfs_register call succeeded the add_disk function is called and also the disk is deleted iff it was added I poped the fake_ide test up to the caller (ubd_add) of make_ide_entries so it is only called when it is to be used ubd_init now uses the char name for both real and fake devices so they should not overlap ubd_revalidate is gone as it is now folded into ubd_add fakehd and fake_ide now are part of fake_major, this is not strictly necessary but they would seem to apply better to the fake major rather than the real device The devfs files are now under /dev/ubd/discX/disc instead of /dev/ubdX/discX/disc the fake stuff now shows up under ./dev/ubdX/disc or /dev/hdX/disc which seems reasonable as it is used to fake out stupid installer programs anyway. I am not certain that the fake stuff is producing the required results as I have not used the fake device stuff. I have run it but I have trouble tracing things since I seem to have no frame pointers. I even re-made distclean ... linux after removing omit-frame-pointer from toplevel Makefile Enjoy, James McMechan |
From: James M. <jam...@ho...> - 2002-10-19 10:24:36
Attachments:
diff-2.5.43-2
|
Here is yet another version of the patch to enable partitions on 2.5 This is against linux-2.5.43 + uml-patch-2.5.43-2 I still don't understand what exactly the new spinlocks are locking for. The ubd_add function is only called by the initcall or mconsole and so should not have any races with itself or ubd_remove (which can only be called by mconsole), I suppose if mconsole tried to remove a device during the ubd init, but I am not sure that mconsole is even available during initcalls. I am assuming that the mconsole interface is single threaded :) Similarly fake_major only applies to individual devices at ubd_add time, the only missing part might be the init time fake handle setup being wrong. But the add/remove now insures that the disk structures will not change under a existing device even if fake major is changed and fake_major can only be set from the command line or the mconsole so should also not require locking either. 2.5.43-2 still has the problems of freeing devices while they are in use, this patch should fix that by moving the error exits to the before the deallocation and removes the failure modes when devfs is not present. Note that if alloc_disk fails on either the normal or fake device that the other can now continue, I admit that if alloc_disk fails there are likely other problems present but at least this version will let what worked proceed and allow it to be disposed of in ubd_remove. I pulled fake_ide up to the call of make_ide_entries so it is clearer what is supposed to be happening This patch also adds a bit of the module locking by setting the .owner field but the initcalls will not permit it to be a module but it is closer and then we could add it like ide/scsi from a initrd. This also restores the /dev/ubd/X & /dev/ubd/discX/disc device names the problem is that if ubdX is used in the gendisk struct name we get /dev/ubdX/discX/disc which is not what was desired. The fakehd_set should I believe work on the fake_major devices since they do not have the ubd naming problem /dev/ubd_X/discX/disc is not so much of a problem if the main /dev/ubd/discX/disc is also available, these are devfs examples. And the fake_major will handle /dev/ubd_X since that is what it had before correct? I don't quite see what the value of /dev/hdX+'a'/discX/disc devices are they supposed to be something else or are they only for the /proc/partition information? Note that: ubd_remove still does not use the ubd[a-h] device names it is numeric only. There may also be a race between add_disk and ubd_close in ubd_add if add_disk is asychronous i.e. submits the queued partition check and returns without the queue finishing This patch does not correct the core fs/block_dev.c which had a missing bd_invalidated I believe the patch has gone to lkml from at least someone from linux-usb-devel, fdisk may still need a uml_mconsole remove/config to update its partition tables as the RRPART ioctl was broken in the filesystem core (or apply that patch I sent "Re: [uml-devel] updated ubd_kern for the uml-patch-2.5.41-1" on 2002-10-11 10:30) This patch boots for me :) Enjoy, James McMechan |
From: James M. <jam...@ho...> - 2002-10-20 18:51:39
Attachments:
diff-2.5.43-3
|
linux-2.5.43 + uml-patch-2.5.43-3 gave me build problems as I was working on the uml-hcd driver I chased down a couple problems includeing the long standing zlib problem. The zlib problem is that zlib requires that lib/Config.in be souced to set the CONFIG_ZLIB_IN/DEFLATE vars for the automagic build scripts to actually build the targets. This also fixes user_syms.o by adding it back into the object list and updateing the $(CFLAGS_$@) to $(CFLAGS_$(@F)) so that it does not have the dir name in the CFLAGS_ name it tries to build, which really breaks the compile because it did need the file specific options, and CFLAGS_arch/um/kernel/user_syms is a mess of a option. I also added two more exports though these may be in the wrong syms.c file |
From: Rainer E. <ra...@el...> - 2002-10-20 21:24:52
|
James McMechan wrote: > The zlib problem is that zlib requires that lib/Config.in be souced Thanks. That builds and works. I build all modules that use zlib, but tested runtime only with 2.5.44-1 and a cramfs disk. -- ra...@el... |
From: James M. <jam...@ho...> - 2002-10-26 09:19:41
Attachments:
diff-2.5.44-1k.txt
|
After the cleanups for ubd_kern.c I have been working on the fake_major stuff. This gets rid of fake_major_allowed as it is not needed the fake_major var itself can be used, also the test of fake_major existing is now against MAJOR_NR rather than 0 so that 0 can be used as a fake_major. This allows the slightly insane automatic block device major number to occur for testing. This looks like it will be needed for the ubd-many patch later :) This also updates the DEVFS_FL_REMOVABLE to DEVFS_FL_DEFAULT this prevents the bdev->bd_contains != bdev BUG() from occurring in full_check_disk_change in fs/block_dev.c:548 as it attempts to rescan the partitions on devfsd startup with the device closed. This also means that the fake major is not automatically updated with the new partition map on fdisk either :( but at least it does not BUG() anymore :/ It also corrects the error exit paths in ubd_add, in the 2.5.44-1 version it could return with the device left open. ubd_config and ubd_remove now use the same code for decoding ubd[a-h]|[0-7] and checking 0<= n <= MAX_DEV I also initialized ubd_fake_dir_handle so that if fake_major is not set at ubd_init and is set by ubd_config it is no longer used uninitialized. However for some reason I have not yet traced down "uml_mconsole 1 ubd=3" becomes "ubd=/home/uml/3" when passed to ubd_config this makes setting fake_major currently impossible I used gdb to test setting fake_major, it looks like it will eventually work, the block register will have to be attached to udb_new_device instead of in ubd_init. After setting or changeing fake_major the ubd_add works ok and seems to set the gendisk correctly. |
From: James M. <jam...@ho...> - 2002-10-29 07:57:07
Attachments:
diff-2.5.44-1m.txt
|
Continuing from my previous patch I now have multiple major numbers working :) during testing I had one partitioned boot disk and added 400 disks through uml_mconsole using ~29M in /proc/meminfo on UML. This was not very fast to setup on a 200MHz/128MB machine but it ran fine once all 400 disks were setup, that is not a limit but rather where my UML started to run low on memory. This used 26 major numbers for ubd, dynamically allocated. I still have not figured out how to force devfs to produce good names the /dev/discs dir has the disks in order of addition :( and I could not get more than 16 discs in /dev/ubd without overlaps so ubd_(MAJOR) is used to house the extra majors This is a patch against vanilla linux-2.5.44 + uml-patch-2.5.44-1 and contains the previous patch also. Not heavily tested but it booted for me and uml_mconsole config/remove worked for ubd400=COW400,fnark.img During testing I noticed that ubd0_init is not called before the setup calls for the command line options, I am thinking that it could be moved to ubd_init and drop the extra initcall. |
From: James M. <jam...@ho...> - 2002-11-02 10:46:51
Attachments:
build-script
build-patch
|
This patch allows 2.5.45 to build for me, I had to manually fixup the symlinks with the attached script. 2.5.45 does not create the devfs partitioned disc files e.g. /dev/ubd/discX... but I was able to boot a partitioned file system, the initscripts dropped me to single user mode. A bigger problem is that the __setup functions don't work correctly yet. I had to manually setup the ubdX= and root= options by (in the linux debug -> gdb window): (gdb) print ubd_dev[1].file="COW1" (gdb) print ubd_dev[1].cow.file="fnark.img" (gdb) print saved_root_name ="6213" this sets the boot to ubd1=COW1,fnark.img root=6213 which will open ubd1 with a cow file called COW1 for the image file fnark.img and root is ubd (62) device 1 partition 3 for people who use ubd0=root_fs root=/dev/ubd0 it would look like this (gdb) print ubd_dev[0].file="root_fs" (gdb) print saved_root_name ="6200" This patch also removes the requirement for qt-devel that 2.5.45 has, I could not even make ARCH=um distclean or menuconfig since I didn't have qt-devel installed. |
From: James M. <jam...@ho...> - 2002-11-12 04:06:59
Attachments:
build-2.5.46
|
Ok, here is a patch to allow 2.5.46 to build. I have been unable to fix up where the initramfs is building the cpio archive which I belive is the reason the current version cant find the root device :( Also I am still having the problem with the __setup functions not being called. This patch is mostly fixups to the build depend order so the things are built after their dependencies Anyway for your enjoyment a patch to build 2.5.46 James McMechan |
From: James M. <jam...@ho...> - 2002-11-13 06:27:10
Attachments:
build-2.5.47
option.dat
|
Hello, I have finally gotten 2.5.47 working correctly for my configuration. The __setup problem dates back to a core linux rename setup.init vs init.setup The initramfs needed LDFLAGS_BLOB and the 2.5.47 fixes to build correctly, it is also now in the uml ld script I have included the latest partition fixes, you could instead use the second patch, in place of the ubd_*.c parts, of the first patch but I have trouble booting without the partitions and devfs fully working. This has the speed up fix for the COW file system setup where I was running ~ 32,000,000 write in the loop, now it uses lseek going from O(1) -> O(0) i.e. linear time: one syscall per 16k of disk image to constant time: one syscall for the COW file in place of that loop yeilding a fraction of a second in place of several (many? I gave up after a few hundred thousand loops) minutes, which may be why there were reported performance problems with COW Now you can enjoy booting a 2.5 kernel once more :) James McMechan |
From: James M. <jam...@ho...> - 2002-11-14 16:04:07
Attachments:
diff-2.5.47b
|
This patch is still against vanilla linux-2.5.47 and adds in the bits from 2.5.44-1um I had neglected to check if they had made it into 2.5.45 and apparently they didn't so here is a 2.5.47 that boots for me :) with the highmem and port fixups from 2.5.44-1um It includes my latest work on ubd include the COW file creation speed up and the multiple disk features. I set it up early this morning with 400 disk images |
From: David C. <da...@da...> - 2002-11-14 16:39:24
|
Hi James, > It includes my latest work on ubd include the COW file creation speed up and > the multiple disk features. Do you have your patches on a site anywhere? If not, I'll happily host them on usermodelinux.org (or, even, patches.usermodelinux.org) - If you've got them somewhere, let me know where they are so I can link to them. I know I've had to hunt through list archives to find them, so I'd assume others have too. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: James M. <jam...@ho...> - 2002-11-14 22:28:11
|
> Hi James, > > > It includes my latest work on ubd include the COW file creation speed up and > > the multiple disk features. > > Do you have your patches on a site anywhere? If not, I'll happily host > them on usermodelinux.org (or, even, patches.usermodelinux.org) - If > you've got them somewhere, let me know where they are so I can link to > them. I know I've had to hunt through list archives to find them, so I'd > assume others have too. > > David No, I don't have a web site anywhere. And I would be happy to have them on your site. How would you like me to package them. That last patch has a forward port of 2.5.44-1 + many-ubd + COW-speedup since that was what I wanted to boot with and my default setup won't boot properly without partitions and the devfs changes. I also have the uml usb host controllers uml-hcd and uml_umusb for 2.5.4? and 2.4.19 which is why I was trying to run the latest 2.5 since USB is changing so fast. I should also back port the ubd-many and COW-speedup back to 2.4 kernel since they are useful there too, COW-speedup would seem the first to work on since I like my ~32,000,000X speed up when setting up the COW file. The ubd patch does not play well with the recently mentioned mmaped disk-image-files since I can't quite picture mmaping 1000 x 512GiB images in one address space :) but I would still like to be able to have insane numbers of disks with huge amounts of disk space, I would prefer to use my limited address space for keeping a few COW bitmaps around. I know it is silly but why not have 1024x512GiB disk imagess and try to crank LVM2 around a 512TiB array :) I can resend the patches as E-mail or if you have a ftp drop box or want to setup a ssh/scp drop box I could send it that way And Re: @usermodelinux.org sign me up. |