Re: native win32 aufs

>>> Adrian Chadd wrote
> Hrm. See, I'm willing to bet that you're using the same basic
> stuff in store_dir_foo and store_io_foo that exists in
> the aufs versions. If so, I think its time to tidy up this
> code a little and have a "unified" ufs directory type
> with different IO types.
>
> What do the rest of y'all think?

Yup.

Taking sfs_interface.c as a guide, the following happens:

fs_interface.c - defines all functions callable by squid. Maintains list of
pending and done requests for actual calls to fs. Request comes in (say,
fsOpen), it builds a request structure of it's own, dumps it on an internal
list of requests, and waits for the actual fs libraries to satisfy the request
- actual ufs, fs, and awin32 code would have to provide a function which is
called when waiting (equivalent to _sfs_waitfor_request(req) atm), so that sync
fs'es can call their actual code in that function, while async just waits for
request to have been satisfied. fs_interface.c code then moves the completed
request data back out onto modio "done" list.

Can we pass the actual requestor through the fs'es guts? I think not, because
we want to store fs-specific info on a requestor as we do that, but will keep
that in mind.

I'm going to start work on this today. This rolls into fs_interface.c also
maintaining an index of files it's responsible for on a per-fs basis, merging
in with modio work.

Anyone see anything broken in the above, let me know ;) Oh, I'm working in
the sfs branch - it's the branch I've got open atm, I need the sfs code for
reference, it'll mean changes to sfs code as I go, and I'm not comfortable
with starting a new branch etc. yet. And it's all self-contained anyway.
I'll have to work out how to get the awin32 code in, tho ;)

KevinL
Received on Fri Mar 16 2001 - 18:10:33 MST