Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!toe.CS.Berkeley.EDU!bostic From: bostic@toe.CS.Berkeley.EDU (Keith Bostic) Newsgroups: comp.os.386bsd.questions Subject: Re: 386BSD vs BSDI Date: 4 Mar 1993 20:07:11 GMT Organization: University of California, Berkeley Lines: 73 Message-ID: <1n5nhf$k5d@agate.berkeley.edu> References: <1moeeuINNoo1@usenet.INS.CWRU.Edu> <1993Mar2.192941.8458@igor.tamri.com> <1n0mgmINNjat@ftp.UU.NET> <1993Mar3.120727.11788@igor.tamri.com> NNTP-Posting-Host: toe.cs.berkeley.edu In article <1993Mar3.120727.11788@igor.tamri.com> jbass@igor.tamri.com (John Bass) writes: >>You cannot copyright an interface. And a function's name and arguments >>is an interface, and, for the ones you picked out, need to be described >>somewhere, so third-parties can add device drivers and the ilk. > >Sorry Sean but I don't buy it ... device drivers have no business calling >breada, bawrite ... etc. These routines are internal routines for >supporting the AT&T file system & buffer cache design. The buffer cache routines are much more than `internal routines'. USL's Device Driver Interface/Driver-Kernel Interface Reference has manual pages for the buf structure (including complete descriptions of all of the B_WHATEVER flags), and the functions biodone, biowait and brelse. AT&T's Block and Character Interface (BCI) Driver Reference Manual includes manual pages for the same functions as well as the buf structure. Janet Egan's textbook `Writing a UNIX Device Driver' discusses the UNIX block I/O routines and structures in great detail. Here's a sample paragraph: b_iodone This field can be used to hold the address of an I/O completion routine. If it is non-null, the routine at that address will be called by the biodone routine with a pointer to the buf as an argument. In System V Release 4, the B_KERNBUF bit must also be set in b_flags in order for the completion routine to be called. In 4.3BSD, the B_CALL bit must be set. USL's purpose in publishing these interface standards was to enable vendors to build device drivers, file systems, and other pieces of software that would be compatible with many different versions of their system. (Yes, file systems can be portable. See S. Kleiman's paper "Vnodes: An Architecture for Multiple File System Types in Sun UNIX".) It can hardly surprise anyone that creators of other operating systems would want the device drivers and file systems written by 3rd party vendors to also work with their operating systems, and, therefore, would provide functional interfaces that are equivalent to the ones that USL documents. USL has chosen to make these interfaces available to the general public without licensing restrictions. They can hardly claim that users of those interfaces must be licensees of their product. > Simply not wanting to invent a new buffer cache design and modify the > filesystem to use it ... is not a valid reason for UCB/CSRG attempting > to place the internals of the AT&T design into public view. I don't think I could name a single feature of the buffer cache design that isn't documented in unlicensed literature. To give you an idea of the extent to which these routines are documented, here's one paragraph from HP-UX Kernel Routine Reference Pages: The iowait routine sleeps on bp until I/O is complete. iowait is awakened by a corresponding call to iodone. When iowait is awakened, iowait checks if B_ERROR in bp->b_flags is set. If B_ERROR is set, iowait sets errno to the value contained in bp->b_error. iowait then returns to the calling routine. If your driver calls iowait, your driver must issue a call to iodone() when the I/O completes. >MINIX/LUNIX and many other OS's both before and after UNIX have managed >to implement filesystems and caches with completely different internal >designs ... it isn't like there is just one way to do this job. If you don't want to be, for example, device driver compatible with other variants of UNIX, your statement is correct. If you have no interest in trying to convince the rest of the world that they should rewrite all of their device drivers, the functionality of biowait/iowait is fixed, and cannot be changed. Keith Bostic CSRG