Date: Tue, 13 May 1997 19:23:51 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-current@freebsd.org (FreeBSD-current users) Subject: Re: Big problem with b_blkno Message-ID: <19970513192351.KJ04154@ida.interface-business.de> In-Reply-To: <Pine.BSF.3.95q.970513180105.947E-100000@herring.nlsystems.com>; from Doug Rabson on May 13, 1997 18:06:09 %2B0100 References: <19970513181525.ZO49600@ida.interface-business.de> <Pine.BSF.3.95q.970513180105.947E-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Doug Rabson wrote: > NFS' use of b_blkno is about as bogus as it gets. Have a look at > nfs_bmap for instance. Actually, I think vfs_bio.c's habit of comparing > b_blkno to b_lblkno to decide whether it has called VOP_BMAP yet should > rank pretty highly on the bogus usage stakes. :-) Anyway, that doesn't bring us a single step further towards a solution of the original problem... We simply can't live any longer with b_blkno being counted in terms of any predefined blocksiz. Support for things like reading non-data CDs won't be possible otherwise. Not supporting it in the kernel will lead to userland solutions that are hard to maintain, violate layering, and duplicate code. Look at Linux's cdwrite command to see three different layers smashed into a single large blurb: the hardware handling, the preparation/action/etc. for actually burning a CD, and some form of a user interface. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970513192351.KJ04154>