--924gEkU1VlJlwnwX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Dear Jason,

On Wed, Jan 04, 2006 at 09:09:57AM -0800, Jason Thorpe wrote:
> So, you're reading a structure from disk and storing it directly in  
> the udf_inode (or whatever you call the v_data structure)... I guess  
> that's one way to do it... UFS does it a different way... it bread 
> ()'s the data, then copies the data from the on-disk representation  
> into a (more convenient) in-core representation, possibly byte- 
> swapping it.

this copying is what i tried to avoid too though argumently it could be 
considered more atomically read/write and take the copy for granted.

> Anyway, what you're really looking for is "struct buf as an I/O  
> descriptor".  Lots of parts of the kernel do what you're doing  
> already.  They don't use getbuf() / brelse() at all.
...
> Some of them dynamically allocate the buf from the bufpool using  
> pool_get()/pool_put().
> 
> I don't see any reason to muddy the buffer cache waters anymore than  
> they already are by adding B_MANAGED (or B_EXTERN or whatever).
...

one of the goals was rather to un-muddy the buffer stuff i.e. cleaning up 
by trying to orthogonise buffer flags and actions. Splitting up the struct 
buf came to my mind too but i considered that to be too big a change for 
now.

One of the results of the orthogonising efford was the introduction of the 
B_MANAGED. Origionally i only intended to put the RFC on the B_NESTED 
proposal but since part of what was needed also included the not owning its 
memory space i introduced the B_MANAGED.

> Eventually, what we probably ought to do is break "struct buf" into  
> two different types:
> 
> 	struct bio -- This is the I/O descriptor.
> 
> 	struct buf -- A "subclass" of "struct bio" that handles the caching  
> aspects.

maybe with a generic callback that takes as 1st argument a reason for 
calling ? But speaking of wich... if there is no plan laid out for it, 
shouldn't we then at least try to arthogonise the functionality and clean 
up the special cases first so we end of with easier to replace items?

Cheers,
Reinoud

--924gEkU1VlJlwnwX
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ7xGu4KcNwBDyKpoAQIMZAf/SrH5Mg5WtBNtKf+J8Lr4AhY4QanszLTl
ye2QwW4UAligCujBEX8jqOo+B/eXt/Bnntn4neZy808a/1Xn7XClBTvAoPFNEJnm
I1ZS6xc2oLanyPS+2CHzKhHkMUPUMPZzJItkoTxJUrBBJ35O0EQeWsWaSX4HzHl5
DECe92Y9S5Xfy0NSGP2C8ha7SCjikfq9g7jIpAuQjCG6rk/31WRuYCF9diyh4RH1
IqKmjI4j93VtD/PKPgXcJCBVq1aXWWvr7MmJjMhnIQid1kcPgaCUZLMS8AQ8azOw
+7sRUA8cq4EtNm4WKN9c676TW0X4w4X3Tvh61l4SiUmtDadZPqyHCw==
=GMf9
-----END PGP SIGNATURE-----

--924gEkU1VlJlwnwX--