--LZvS9be/3tNcYl/X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Dear Yamt,

On Mon, Jan 09, 2006 at 01:04:38PM +0900, YAMAMOTO Takashi wrote:
> the above comment was after seeing your latest patch.
> my question is, what is "its own use".
> i don't understand why your "less intrusive" version can't use b_private.

it could though aren't there allready a lot of situations where devices 
bluntly use the b_private? or are you sure they only use that on their own 
created buffers? IF they would bluntly overwrite/use b_private it could 
result in a panic or am i paranoid in this?

> > A simple deligation system might be plausable in the future design to 
> > greatly reduce struct buf sizes and provide more customised design without 
> > the need for the overloading and/or adding of variables.
> 
> what you want is an API to reduce the code to touch bp->b_* directly?
> if so, i'd suggest something like the attached patch.

offcource, that was my intention too from the start. I've looked at your 
patch and can agree with it (though i haven't tested it yet) but its 
important to also export nestiobuf_iodone() to provide support for custom 
callbacks.

Furthermore it looks like you took a rewrite/simplification of genfs as 
basis and created the nestediobuf semantics from that whereas my 
implementation started as a mechanism and i modified genfs to use it.

It solves one minor issue i've overlooked but thought of y/day night: the 
case that no subbuffer was issued. Your explicit nestiobuf_done() solves 
this.

Do you plan to commit it soon?

Reinoud

--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAwUBQ8JpHoKcNwBDyKpoAQK+dwf/ax3X2AgjSWbvvt1EEQZCzQ5E4qkHmbCm
CplOcX6VlyvjayBvTRLUTKRL/j4B5tVMcCVGuYyUjAnf6C6coU6a0KaDUt1iqSNL
Pg9GjjXI+tIydWKurfcXUy124npzh46uboHioLdMTD7GXVDNd0Zc/vp7wvmhxSxV
x6DVXNdHUBYrTWnYX8EJ8Bzvk1c+/Y+DUL5TYgsyxFzcijgh4EoZi9yqH6IBbXF7
au2MI7rvK8H1qg3RsvNmwvLh08JP31mRlx5IrbhZLhTN0jHcUKdn7G0IOSl8OUfl
Iibe7rfdBDVd/xiPgmlpKHb5KIcVTwSoGopWD1rO2V3tKyyBFQ4TZA==
=ZV0P
-----END PGP SIGNATURE-----

--LZvS9be/3tNcYl/X--