On Tue, Jul 01, 2003 at 08:03:52PM +1000, Andrew Over wrote: > On Tue, Jul 01, 2003 at 12:47:22AM -0800, Ethan Benson wrote: > > > i tend to think that its better to have a verify() for each filesystem > > so we can probe for filesystems without really commiting to opening > > any particular file. (this would be useful for example if we make > > some sort of function call to return a list of partitions on a device, > > complete with what filesystems exist on them). > > I tend to agree. At least with verify it's possible to have a > meaningful return code, whereas open will be stuck returning > ENOENT/EIO/ENXIO (to be honest I can't think of an immediately > appropriate code unless you want to define EWTF or some other new code). yes, id rather keep open() as compatible as possible with established unix practice. as for errno you can see which i have defined in my errno.h. its a small subset of what is in usual unixes since i don't expect to need many of them. the only semi-nonstandard one is EFSCORRUPTED which comes from IRIX/XFS. i use this as a way to convey unsupported filesystems. errno itself isn't really standardized at all anyway, rather certain functions have specified errno conditions. > I took a quick look over the existing vfs.tar.gz, and it looks like a > good approach. yes it is, the person who wrote is a very talented coder and designer, its unfortunate he has decided to cease his assistence. > My initial instinct was to try mimicking the linux vfs > layer, so that filesystem code could be borrowed with minimal effort, > but that idea lasted all of about 20 seconds once I started looking at > the source, mostly due to the close relationship between the vfs and the > vm subsystems. exactly. also one other point, i would very much prefer to keep all code under the GPL v2 or optionally later version licence. i don't want to be locked into GPL v2 only which is where the linux kernel is currently. (lockin to specific GPL versions is going to cause code sharing headaches in the future when GPL v3 comes out). currently 100% of prom-libc is under GPL v2 or later. > ... which brings us back to determining a reasonable set of callbacks > to operate a filesystem from a generic layer. I *think* a standard > open/read/seek/close/verify would probably suffice for file IO, probably > with an additional init/exit callbacks for the filesystem drivers to > deal with internal state. If you ever want grub-style tab completion, > you'll need opendir/readdir/closedir or equivalents. correct, opendir/readdir/closedir has always been part of my plan as well. lets us get ls and such too which grub lacks (grubs tab completion is a horrible kludge...) > I'm assuming for the moment, that we don't need write support. no not really. in most modern filesystems its quite complicated, and not worth the risk. however we DO need write() to work as printf() et all use stdio which uses unix io. but for actual filesystem drivers themselves its perfectly acceptable to just return EROFS on any attempt to open something with write perms. ive also pondered it might be useful to be able to write debug data or some primitive crash dump to a scratch partition. > In fact on closer inspection, a modification of the existing io_manager > approach looks fine. The short version is have an object representing a > file/device. Upon a call to open, call ->verify() functions to figure > out who can do it, initialise a structure inside the object with the > appropriate set of function pointers (ie open/close/...), and away you > go. The remainder of the code need not know anything, and can just use > the function pointers. This means the addition of an appropriate > pointer to an __fsdriver object, but otherwise minimal changes. yes we (original contributor and i) noticed how the libext2 io manager somewhat resembled what we were attempting to build. > Just a few random thoughts: > > - Does this level of abstraction suffice? Can anyone think of any funky > things the bootloader might want to do in the future? keep in mind that prom-libc aims to be general purpose, while primary audience is bootloaders it potentially could include some other esoteric program. but as benh pointed out i want to implement the standard networking interface as well, so we can do tftp, nfs etc. > - Buffering? I notice at present there is a flush function, but I > assume this will remain a NOP, unless we find an OF with a sync() > function (does it have one?) Sun OF has a sync. but you are correct that i don't implement any buffering in stdio. i don't consider prom-libc an OS, so that level of performance optimization is not necessary. i implemented fflush() for compatiblity reasons (some code in yaboot will be shared with ybin, so i try to keep things as complete as possible, without getting too silly). > - It's probably easiest to insist that the filesystems only read/write > blocks, and allow the upper layer to handle smaller chunks. no i think this would be problematic. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgp00002.pgp
Description: PGP signature