From owner-freebsd-arch Mon Oct 18 10:36:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BE9F114E40 for ; Mon, 18 Oct 1999 10:36:39 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA25678 for ; Mon, 18 Oct 1999 19:36:38 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA78810 for freebsd-arch@freebsd.org; Mon, 18 Oct 1999 19:36:38 +0200 (MET DST) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id E2E1814E40 for ; Mon, 18 Oct 1999 10:36:22 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.9.3/8.9.3) id KAA26646; Mon, 18 Oct 1999 10:35:55 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp01.primenet.com, id smtpdAAAjfay6Z; Mon Oct 18 10:35:47 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id KAA03508; Mon, 18 Oct 1999 10:35:46 -0700 (MST) From: Terry Lambert Message-Id: <199910181735.KAA03508@usr07.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 18 Oct 1999 17:35:46 +0000 (GMT) Cc: freebsd-arch@freebsd.org In-Reply-To: <6173.940266501@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 18, 99 07:08:21 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is my last set of words on this subject... > >> 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 ? I think this is an invalid assumption. It is needed in order to comply with POSIX, if for no other reason. The idea that, if someone can't think of a use for something, and another person can, but that use is not seen as valid by the original someone, is a Very Bad Precedent. BSD is a research OS, and a research OS _must_ not, by its nature, limit the directions of future work. But even a research OS should be prepared to at least have a seperate mode in which it complies with standards. I would like to suggest that someone contact John Dyson, so that he can tell us how the FreeBSD Oracle port operates, and whether it needs block devices. I know that the IBCS2 emulation under which Sybase can run on FreeBSD _does_ need this. I also believe that Solaris emulation requires this for their packaging tools to operate properly under emulation. I would argue that people need the functionality. But even were you to prove that people didn't need the functionality now, given a willingness to bloat large amounts of user space code in order to cope with the lack of a traditional kernel service, you will not be able to prove that the functionality won't be needed at some future point. > >> 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. This would be the provenance of a filesystem, not an application, in my example. The reasoning behind this is to present, as files, raw audio and DVD data to a variety of applications which would *NOT* need to have the knowledge of the data format, other than as a linear array of bytes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message