Do we still need ATA disk CHS addressing?

[Alexander Motin]

M. Warner Losh wrote:
> In message: <4A807BDD.6040709 at FreeBSD.org>
>             Alexander Motin <mav at FreeBSD.org> writes:
> : Warner Losh wrote:
> : > My question, and maybe I missed this earlier in the thread, is what's
> : > the benefit to removing this support?  How much code is saved?
> : 
> : It is not about code size, but about code structurization. ATA(4) has 
> : too much cross-level relations, making it cryptic. I am trying to unroll 
> : some of them to simplify code.
> 
> Can you explain a bit more here...  How pervasive is it, etc...  I'm
> not saying this is a bad change, but I think people wishing to remove
> stuff should at least have a good result that's expected...

Do you really wish to touch it? Fine... CHS translation is now done on
ATA controller drivers level. To work properly it needs data from drive
IDENTIFY structure fetched from drive and stored on higher level. To
wrap legacy ATA into CAM SIM I need to break that dependency either with
dropping this functionality or reimplementing it on higher level. I
would prefer first.

> : > Having said all that, I think it is OK, but I'd definitely poll the
> : > pc98 guys first...  Just to make sure they don't need it and re-fork
> : > the ata driver to get it :)
> : 
> : GEOM has no terms of cylinders/heads/sectors, in fact it works only with 
> : LBA. CHS translation is only needed for drives, that have no native LBA 
> : support. It is not about disk partitioning or label format. It is just a 
> : method to linearize nonlinear address space of ancient drives. For last 
> : 10 years, since drives lost their classic geometry, drives are doing 
> : this translation on firmware level.
> 
> GEOM does have terms of CHS when it reports the classic geometry of
> the device.  That can't be lost, or pc98 partitioning breaks.  And the
> geometry reported must be massaged too, but that's a different issue.

That's completely different, and I am not going to touch it.

> The disk requests can be LBA, since the driver is responsible for
> changing that anyway...  I don't think that there's any supported
> pc98 hardware that would break, but I'm not 100% sure...
> 
> There's also some oddities at the lowest levels for pc98 controllers,
> but I don't think this change would affect that.  However, like I
> said, ask the pc98 guys for sure.

As you could see reading above thread, I have agreed keep it in legacy
ATA mode. But it looks pointless to support it in new development.

-- 
Alexander Motin