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--