From owner-freebsd-bugs Thu May 11 11:09:52 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA08793 for bugs-outgoing; Thu, 11 May 1995 11:09:52 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA08781 for ; Thu, 11 May 1995 11:09:49 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA00919; Thu, 11 May 95 12:02:56 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505111802.AA00919@cs.weber.edu> Subject: Re: problem for reading old CD-ROM To: rgrimes@gndrsh.aac.dev.com (Rodney W. Grimes) Date: Thu, 11 May 95 12:02:56 MDT Cc: ohki@gssm.otsuka.tsukuba.ac.jp, freebsd-bugs@FreeBSD.org In-Reply-To: <199505111756.KAA10636@gndrsh.aac.dev.com> from "Rodney W. Grimes" at May 11, 95 10:56:30 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > I am not sure, I need to go check my iso 9660 spec, but it seems to me > that 512 byte logical blocks are a violation of of the spec. Changing > the cd9660 code to read non-conformat cd-roms, IMHO, is an ugly hack > at best. I disagree about the ability to read non-conformant CDROMs. Unfortunately, there's not a sticker that they can only display if they conform, and the public doesn't only buy them if they conform. > Changing block device code to do unaligned block transfers is even > worse :-(. This I definitely agree with; if the code is going to be bastardized, better to do the deed in the FS specific code by buffering more than necessary in and hanging it off the in core version of the vnode after translation instead of hanging it off the vnode in the normal place. This is the same type of hack that's needed for a block compressing file system. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.