From: James M. <jam...@ho...> - 2002-01-11 01:36:51
|
>From: Jeff Dike <jd...@ka...> >jam...@ho... said: > > I would usually handle the ubd_user.c(2.4.17-4):375-382 reading like > > this: > >Yeah, that looks right. > > > I had a different usage pattern for the COW files and so usually > > treated linux/COW/root_fs as a triple to be copied about. > >Ultimately, what's going to happen is that filesystems will be packaged up >as RPMs and debs and installed readonly in a central fixed location. >Absolutizing backing paths is the only reasonable thing to do in that case. >And I don't see any reason you couldn't continue working with your roots >in a fixed place. > Yes, when I was composing my first email (at 4am) my thinking was a bit muzzy I also see no problems with e.g. /usr/lib/uml/rh7.2 as a shared readonly root filesystems. > > > I am still working on ubd.c partitions and dynamic major numbers > > (kmalloc a new device) but I am still fighting with the ubd.c/ > > ubd_user.c communications and the blk.h macros like CURRENT, > > QUEUE_EMPTY and end_request. > >I recently looked at making ubd=<n> work again, and the current driver (and >block layer) doesn't make that easy. CURRENT expands to the request queue >head of the UBD_MAJOR blk_dev. So, if you make the driver take on another >major, requests will be queued to that blk_dev, and CURRENT won't see them >because it has UBD_MAJOR built into it. > >I would like one request queue even if it is using more than one major and >I don't see a clean way to do it. > > > I would like to use the request queue to find the current request. > >blk_dev[major].request_queue.queue_head > Yes, I tried unwinding the CURRENT macro; defining MAJOR_NR as a varibile works somewhat and other numbers can be used. But I need to extract either a index number or a major number out of the io_thread_request, at the moment I was considering using a lookup from the req.fds into the ubd_dev[] arrays fd or cow.fd elements (ick but should work) and then the macros will work. > > > Also where does ubd_handler get the io_request_lock from so it can > > call do_ubd_request? (end_request requires it I think) > >I think it's held by ll_rw_blk, but I'm not sure. > Well maybe, but I did not see ll_rw_blk on ubd_handlers gdb backtrace. I was thinking since it appears to be a interrupt handler that like hardware interrupt handlers it should start a bh/tasklet to acquire the lock and finish the I/O. At the moment I have up to 16 disks working both as boot devices (8) and partitions (all 16) I still need a little work on DEVFS flags and check media change so that the devfs disc/part## are created properly on a uml_mconsole config, though even now I can boot off a partitoned disk and see/mount the partions, /proc/partitions also works _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com |