Re: native win32 aufs

I can drop you a patch against head with the awin32 code. All it changes
is
configure.in
aclocal.m4
acinclude.m4
new directory src/fs/awin32

Rob
----- Original Message -----
From: "Kevin Littlejohn" <darius@bofh.net.au>
To: <squid-dev@squid-cache.org>
Sent: Saturday, March 17, 2001 12:10 PM
Subject: 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:19:13 MST