From owner-freebsd-arch Wed Oct 13 16:46:11 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 CCAEE14ED4 for ; Wed, 13 Oct 1999 16:46:02 -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 BAA26860 for ; Thu, 14 Oct 1999 01:46:00 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA39270 for freebsd-arch@freebsd.org; Thu, 14 Oct 1999 01:45:45 +0200 (MET DST) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id E51D814FEE for ; Wed, 13 Oct 1999 16:45:29 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id QAA22274; Wed, 13 Oct 1999 16:45:25 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpdAAAzZaaaR; Wed Oct 13 16:45:00 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA24624; Wed, 13 Oct 1999 16:44:53 -0700 (MST) From: Terry Lambert Message-Id: <199910132344.QAA24624@usr01.primenet.com> Subject: Re: The eventual fate of BLOCK devices. To: mckusick@flamingo.McKusick.COM (Kirk McKusick) Date: Wed, 13 Oct 1999 23:44:52 +0000 (GMT) Cc: julian@whistle.com, freebsd-arch@freebsd.org In-Reply-To: <199910131738.KAA18428@flamingo.McKusick.COM> from "Kirk McKusick" at Oct 13, 99 10:38:35 am 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 > The question is, "How much code will it clear up?" > The opinions differ. > And, just because we can't point out one at the moment doesn't > mean that there aren't any. > > If no one on the list can think of any use, I doubt that there is one. > Just because there might some day be a use is not enough reason to have > an interface. BSD has stayed lean and mean (relative to the commercial > Unix varients) by actively throwing out decrepit interfaces. If we revert > to the vendor `keep every interface that we ever put in the kernel for > fear of upsetting some legacy application' we will end up with a bloated, > hard to maintain, hard to evolve system. We have pitched far more heavily > used interfaces than block devices and been better for it. I agree with this sentiment. However, this seems to argue for pitching character devices, since character devices have the restriction that they must be accessed on block boundaries in block size increments, whereas block devices have no such restriction. When choosing between interfaces, it seems to me that keeping the one with the least restrictions, and pitching the one with the most, would be the more correct approach. I really object to having to modify user space code to know about having to access things on block boundaries, and having to cache a blocks worth of data (dependant on whatever the native block size of the underlying device happens to be) in order to update regions. It makes little sense to do this in many user space programs, as opposed to making the opacity of the blocking a kernel function. With regard to unnecessary block buffering occorruing in the kernel, two candidates ripe for a bullet in the head are directory entry blocks, and the inode hash. The inode hash could be easily eliminated by not breaking the vnode/inode association arbitrarily (perhaps by yielding ownership of vnodes which incorporate inodes at the end of their structure to the FS containing the inodes). The directory entry block code is a historical wart, which has the effect of preventing us from going forward with things like btree based directories, native Unicode support for 256 character filenames (_NOT_ UTF-8 encoded: that would require up to 1280 octets for a worst-case encoding, whereas 16 bit fixed characters require only a maximum of 512 bytes -- but leave no room for directory metadata other than the file name, if limited to 512 byte blocks), multiple namespaces (needed to optimize Samba), ACL's, extended attributes, etc.. Both of these issues are roadblocks to progress... unlike block devices, which may be ugly in some people's eyes. > There is also the issue of Posix standards etc. > is a 'Unix' supposed to have two kinds of devices? > the standards certainly define block and character devices. > might a process use block devices as a mething of allowing > caching between multiple co-operating processes? > > Julian > > Posix defines that there are two types. It says absolutely nothing > about the semantics of the two types. It does not require that you > have both types, merely that you be able to report them if they are > there. As for maintaining caching between processes, we already have > two ways of doing that. FIFO's (a descriptor I/O based method) and > shared memory (obtained via mmap). We do not need another descriptor > based method. > > Kirk McKusick Julian's example of cooperating processes is flawed, since that is an issue for the coherency model to deal with, but his reasoning is not; POSIX states (from the "Go Solo 2" CDROM): character special file A file that refers to a device. One specific type of character special file is a terminal device file, whose access is defined in "General Terminal Interface" in (XBD). ... block special file A file that refers to a device. A block special file is normally distinguished from a character special file by providing access to the device in a manner such that the hardware characteristics of the device are not visible. The standards (POSIX, et. al.) _do_ require both types of special files. 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