*BSD News Article 12342


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