Subject: Re: SCSI MMC device abstraction and UDF patch for review
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Reinoud Zandijk <reinoud@netbsd.org>
List: tech-kern
Date: 12/24/2005 14:41:54
--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hiya Takashi,

On Sat, Dec 24, 2005 at 08:35:22PM +0900, YAMAMOTO Takashi wrote:
> > ftp://ftp.NetBSD.org/pub/NetBSD/misc/reinoud/src-diffs-udf.20051222.gz
> 
> - it seems to do double-caching.  ie. at both of udf and block device.
>   is it intended?

Yes and no. For UDF it is better to use caching in udf since blocks can 
move around esp. on recordables; every disc write changes the location of 
the block so its easier to have it cached on the file's vnode on its 
logical block instead of a moving buffer on disc. Setting B_NOCACHE in the 
buffers passed to the block device is prolly advisable yes.

The two stubs for reading are to be integrated in a safeguard mechanism 
that orders read and write requests in such a way that it doesn't inflict 
adressing issues due to percularities in writing to recordables.

> - "bp->b_lblkno = bp->b_blkno;" in udf_strategy is only for printf?

not intentionally. During developement of the code i read that when the 
logical block number wasn't equal to the blocknumber that it was then 
allready translated with VOP_BMAP and thus could be directed to the 
device's strategy routine. This might be in imported FS though. To assure 
that *all* reads and writes are passed trough UDF i made this explicit 
assurance that all buffers are allways BMAP'd and thus passed trough UDF's 
strategy. This might be based on old or incomplete information but i'd 
rather be safe in this than get surprised later by other parts of the FS 
stack making this assumption.

> - is udf sector size ("lb_size" in udf_strategy)
>   always smaller than or equal to page size?

no... lb_size can be every multiple of 512 in the UDF spec though trough 
limitations in NetBSD the code only accepts lb_sizes in powers of 2. See 
the check in udf_mount(). Most common are 512 and 2048 in practice. Other 
values are more to safeguad implementations to make assumptions on this. 
Would/could this pose problems ?

> - what's the license of udf_osta.[ch] ?

As stated in the file itself, this code is part of the OSTA standard and 
the sections are stated to be:
=====
 * OSTA compliant Unicode compression, uncompression routines.
 * Copyright 1995 Micro Design International, Inc.
 * Written by Jason M. Rinn.
 * Micro Design International gives permission for the free use of the
 * following source code.
=====
FreeBSD and OpenBSD have accepted this license and have allowed it to be in 
their kernel sources. Its shared with Scott Long's udf implementation 
currently used by FreeBSD and OpenBSD.

Hope this answered your questions.

With regards,
Reinoud

--tKW2IUtsqtDRztdT
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iQEVAwUBQ61QG4KcNwBDyKpoAQL1ugf/e+8fj+aLkU8I13JnWySg5HfOgp8HsuWm
yTLl8a8pllobStbYU8rwXbfrDNWcw2Z9wVE0j30r77iT7s0BAq7z4nQKDgTud1Cb
mYJhlJAnfQOECO6TxmAeG0wDAmctsCpZ/+46MQNcn0ONMuAp4P1YYMDFIjwxuSth
Lfp4hGY+V2x8Gs9e1Clan77ZRjW5TNFdFJrVbUGZizKbhBLsylKhrnQt6jMXBZki
R/ppjmElIWYGZLrEHr7jG+m3Glvgpv4tE/vPDxSI7vRbsWiJVY5Sb4vlIPfysIK5
/FUzsKibj8kU8owz8pDM4GzP59Xo5SVITOJ9P4Diaa3+uj5eXPb/QA==
=h2Y5
-----END PGP SIGNATURE-----

--tKW2IUtsqtDRztdT--