It still has most of the original usb-patch but now at least it does not
blow up my machine.
I put in the um_kmalloc in_interrupt() test and finally traced back the
udev=0 problem to the hub port status change routine now it just defers the
rewrite until it can find the hub device successfully.
This version is against uml-2.4.18-41
Also the partial read/write loop could be combined in ubd_user.c and
possibily could be moved out to a file to be shared with uml_moo so that
there is only one COW->backing_file conversion in both uml and uml_moo does
that sound worthwhile?
The part where it was not using start*sectorsize+offset did not seem to
activate in 2.4.x I had tested for any cases of a io_req that did not have a
consistant run, i.e. the bitmap is all one way or the other by the time it
gets to do_io() I seem to remember that it was broken out at a higher level
into consistant runs before being passed to do_io().
I could also try again with the ubd-many structures which did dynamic device
number extension allowing for a few thousand ubd devices. I had not
intended to use ubd[a-z] especially it just seemed to fall that way from the
style of main.c, but that limits it to 26 ubd devices... currently only 8
are allocated though.
The whole disk 0 device /dev/ubda or /dev/ubd0 is (98,0) or /dev/ubd/0/disc
while disk 0 partition 1 /dev/ubda1 is (98,1) or /dev/ubd/0/part1
Get latest updates about Open Source Projects, Conferences and News.