Date: Mon, 18 Oct 1999 19:08:21 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. Message-ID: <6173.940266501@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 14 Oct 1999 16:56:25 PDT." <Pine.BSF.4.10.9910141621480.17468-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.10.9910141621480.17468-100000@current1.whistle.com>, Jul ian Elischer writes: >On Thu, 14 Oct 1999, Terry Lambert wrote: > >> First of all, thanks to everyone for such a focussed discussion. >> >> I have some comments on Poul's comments, and would at least like >> to argue for a "legacy mode", even if it is not enabled by default, >> so long as it can be enabled (and implied) without a kernel recompile >> (but perhaps requiring a kernel module), for standards compliance >> reasons, if no other. > >I have mentionned before, and I will mention again, that if a standard >disk layer is implemented, then it would be quite easy to implement >a block buffered interface to the raw disks, purely within the disk layer. But why bother, if nobody needs it ? >> 5) Programs that have to deal with CDROM's containing multiple >> sessions. >> >> This is an issues, since not all data is 2048 byte blocks, but >> can in fact be 2352, or a physical sector size of 2048, 2336, or >> 2340 bytes. This will only get more complicated as DVD and other >> standards evolve and come online. This is not an issue, since the app needs to know what it is doing anyway. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6173.940266501>