Date: Mon, 18 Oct 1999 17:35:46 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: freebsd-arch@freebsd.org Subject: Re: The eventual fate of BLOCK devices. Message-ID: <199910181735.KAA03508@usr07.primenet.com> In-Reply-To: <6173.940266501@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 18, 99 07:08:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910181735.KAA03508>