From owner-freebsd-current  Sun Mar 21  1:50:59 1999
Delivered-To: freebsd-current@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP id 6D6D415064
	for <current@FreeBSD.ORG>; Sun, 21 Mar 1999 01:50:56 -0800 (PST)
	(envelope-from sos@freebsd.dk)
Received: (from sos@localhost)
	by freebsd.dk (8.9.1/8.9.1) id KAA37222;
	Sun, 21 Mar 1999 10:50:25 +0100 (CET)
	(envelope-from sos)
From: Søren Schmidt <sos@freebsd.dk>
Message-Id: <199903210950.KAA37222@freebsd.dk>
Subject: Re: How to add a new bootdevice to the new boot code ???
In-Reply-To: <199903201930.LAA12494@dingo.cdrom.com> from Mike Smith at "Mar 20, 1999 11:30:31 am"
To: mike@smith.net.au (Mike Smith)
Date: Sun, 21 Mar 1999 10:50:24 +0100 (CET)
Cc: current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It seems Mike Smith wrote:
> > > But hey, I don't have the time to work on ATAPI.  Soren does, so he gets
> > > to call the shots.
> > 
> > Right :)
> 
> ... so we lose.  8(

Well, depends on POV I guess...

> Soren, please take a little time to understand what Justin is talking 
> about.  The parts of CAM that are relevant to you are the queueing 
> support, infrastructure, and the separation between the "interface 
> controller" and the "peripheral driver", something that you've 
> indicated to me several times that you simply don't grasp.

The main driving force here is that I want as much performance
as I can possibly get out of modern ATA/ATAPI hardware, plus
have a driver as simple as possible to arrive at that goal.

However, all that I've been doing so far is to get the lowlevel code
redone so probes are faster etc etc, all the highlevel code is
more or less reused old hat things for now. There is nothing
that hinders anyone in doing all the (apparently) needed changes
to CAM, and have it call what I've (re)done so far.

However I dont have any plans for that on my whiteboard *currently*. 
If consensus can be reached that shows that the project is not 
interested in it being done this way, please, just tell me and
I'll pack up my bits, I can deal with having yet another set of 
patches locally. Can you grasp that ?? (yes offence taken).

> Taking advantage of all the code and design that's already been 
> implemented in the CAM framework will make your life easier, not 
> harder.   It's not necessary to write a translation layer at all, if 
> such a thing offends your sensibilities.

Maybe, later, but I still need to get all the lowlevel stuff into
shape, and have it working on you average ATA/ATAPI iron, which
is not exactly trivial, I need support for DMA on god knows which
different PCI chipsets, I need the lowlevel code to deal with
ATA4's braindead way of doing tagged queuing, etc etc etc..

Then when all this is working we can talk about having the top
layer(s) redone in the CAM way or what we have at that point in
time.

OK ??

-Søren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message