Subject: Re: ATA/ATAPI kernel redesign
To: None <firstname.lastname@example.org>
From: Lloyd Parkes <email@example.com>
Date: 02/27/2002 21:01:37
> Can you be more precise about this ?
The example that I have spotted so far is that wdc.c:wdcprobe sets WDCTL_4BIT
in the auxialiary control register when the ATA spec lists this as a reserved
bit and requires that it be cleared. I don't think that we should go round
setting reserved bits in important registers, and I don't think we should
casually drop support for WDC devices that need this bit set.
> > shouldn't be doing resets (according to the bit if the spec that I recall). I
> I don't recall the specs saying that.
I do recall that, but I've already looked up chapter and verse once today, and
I can't be bothered doing it again. It also isn't worth arguing about until
someone starts actually doing stuff with the code.
> Doing a reset is the only way to have the
> device in a known working state, we can't avoid that.
I think we can, mostly.
> The BIOS or previous OS
> may have done all sort of weirdness to the device, from setting up power
> management to restricting access to parts of the device.
I have to admit that I'm also wary of what the BIOS might do to the device. I
think that we can handle anything except the security restriction stuff, and
now that I think some more, we aren't supposed to be allowed to do anything to
the security stuff. The security restrictions are explicitly designed to
protect parts of the device from the O/S.
What happens if some vendor uses this facility to prevent their on disk
pseudo-BIOS from being overwritten? User X asks NetBSD to use the whole disk
because that's what they did for Windows and blam, their 'BIOS' disappears.
For other more volatile settings, we should be able to set them to whatever we
want, without a reset.
I'm not hung up on the resets as such, it's just that I think the specs says
not to do them and I want us to have a driver that we can claim to be a well
behaved ATA driver. Obviously we need reliability and performance as well, but
I think the boasting rights are good for proselytising(sp?) NetBSD.
> The problem is that, with some controller, you also have to wait 30s before
> you can decide that there is no device here. With 2 channels this makes a
> 1mn delay.
We certainly don't want this. Especially when you can have more than one
controller in a machine. I can now see why you are interested in probing for
devices after interrupts have been enabled. All ATA buses could be probed at
the same time. Marshalling the responses could be interesting, but I'm sure it
can be done.
> I agree that a few things here can probably be improved, but splitting
> the pre-ata support in a different driver is not the way to go. Way too much
> code duplication.
My intention is/was to not maintain the pre-ata support. Yeah, yeah. I know
that it's going to need to be worked on sometimes as the environment
surrounding it changes, but the hardware that the code supports is EOL. On the
other hand, I have been thinking about how much code is in wdc.c (since you
mentioned it), and I have to agree that large scale code duplication is a bad
I have two problems
1) I can't tell by looking at wdc.c which parts are ATA conformant, and which
aren't. I like to fix problems like this by starting with a spec, an empty
source file, and useful code stolen from elsewhere and then procede to build a
conformant implementation while avoiding all the hard work by stealing from
the aforementioned code.
2) The support for old devices isn't as obvious as it might be. (IMVHO - I
haven't looked at this side of things.)
What would be nice to do would be to remove all of the special case support
from wdc.c so that we had a nice simple WDC core that could be used by the ATA
system and by, say, wdc_old.c that bolted on all of the archaic support
required. This is a bit fair of work/thinking though. I like nice clean code
that has all the nasty special cases for broken devices hidden away somwhere.