Date: Sat, 27 Jun 1998 18:57:27 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: current@FreeBSD.ORG Subject: progress report on stuff I'm doing. Message-ID: <Pine.BSF.3.95.980627183028.26893A-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
I've been drawn away doing whistle.com specific work for a while but have got back to FreeBSD over the last few days. I thoght I'd just report in what I'm doing so that others know what I'm up to. I have 5 projects in th eair at the moment. 1/ Soft updates: reliability is much improved but we have at least one crash and a couple of consitancy glitches still outstanding.. I have 50 reports of trouble-free use, and 6 reports with varying amounts of problem. Next week we'll probably look at that again as kirk wil be back in town. 2/ clean-up devsw[] stuff This has suffered a big-time collision with what Poul is doing, so I've backed part of that down and have a set of patches that start to make usage of these structures more consistent. The reason for this is the lead up to the next item. 3/ I have devfs accessing all devices directly without going via the devsw tables at all the devices only access the entry that is exported by the driver, directly from the vnode private information.. The major changes to ge this work that affect OTHER parts of the system are: a/ removing rawread() and rawwrite() and giving each disk-like device its own version of this that skips the devsw[] lookup. b/ adding a vnode pointer to the args for VOP_STRATEGY(). I'm still not sure about VOP_BREAD, that still doesn't have one. This simply usurps all the functions of specfs(), however I cannot remove the devsw tables yet as there are lots of places in the kernel that I am finding that go behind the specfs's back and access the devsw tables directly (e.g in tty.c. ext2fs_vfsops.c, cd9660_vfsops.c etc.) I have not fully investigated all of these yet so have not decided how to bring these "into the fold". If people such as Mike hancock want to look at the patches (particularly the added arg to VOP_STRATEGY) I'd be most pleased to pass them on. the will probably appear on http://www.freebsd.org/~julian sometime today. Poul-henning's idea of breaking struct buf into two parts, one of which describes the buffer/memory space and one of which describes the requested IO is sounding better all the time. 4/ IPFW WORK I will probably be doing some work on ipfw again in the next few weeks as well, and possibly produce a more productised version of the tranparent proxy support from a few weeks back. 5/ SLICE support for CAM. has been on the back burner for 3 weeks due to USEnix etc. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980627183028.26893A-100000>