> 
> 
> > The PCMCIA code, although functional, is considered "bad".
> Maybe the people who consider it bad could explain what's bad about it?
> I've not really looked at it myself yet.
> 
> > You can help by aiding in the effort to partially rewrite it so that
> > it can be integrated.
> Well, given some hints about what to do I'd be willing to help rewrite it.
> That might be a slow process though, I don't have much time to spare.
> 

As one of the "interested, but totally tapped for time" masses, the
problems are purely form (and to some extent, function I guess).

ATAPI should be implemented as "SCSI over IDE".  Theoretically, anything
you do to the SCSI bus you should be able to do to the ATAPI buss as
well.

The current ATAPI driver doesn't.  It treats ATAPI as a third controller
type, kind of a hybrid between SCSI and IDE.  From what I've seen there
are good arguments for both the 'desired' driver and the 'existing'
driver.

Now, for the rub:

If the existing driver gets pulled into the source tree, a lot of SCSI
stuff that exists already gets duplicated, and theoretically maintained
in two places.  This is a Bad Thing.  If a new driver gets written, the
"virtaul machine tar baby" gets loaded.  This, while being stylistically
superior, is (as I've heard rumored) a very tricky bit of code.

Either way, clearly the "SCSI on IDE" method is the goal.  This allows
for all kinds of cool stuff to be added to the system in the long term
without a lot of code impact/duplication.

Unfortunately, the existing driver is there, relieving the pressure to
write one 'correctly' for those people that would want to do that.  

As you can see, it ends up being a low priority task for most folks; the
existing code seems to work just fine (I'm using it on a customer's CD
Server without complaint).  The purists want it to work "like it should"
but don't have the urgency to make it do that, since there is no
pressure, since the existing one works.

The solution:

As I see it, there is only about one solution.  Load the nasty, icky,
poo-poo (existing) ATAPI driver and initiate a PR explaining what the
problems are.  As they get fixed, we slowly back to old driver out and
replace it with the 'all-singing, all-dancing' SCSI over IDE driver.

It's not like we've never used bad code before.  Look back through the
mail archives.  You'll probably find a hundred places where the code
"could have been better" but we used it anyway.  

It isn't like the ATAPI driver is a virus or something.  It's a means to
an end; a solution to a problem.  Someone put in the hours and did the
work.  He should be recognized for that (my opinion, as always) and his
code should be used, at least in the short term.


-- 
Dave Burgess  (The man of a thousand E-Mail addresses)
*bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
"Just because something is stupid doesn't mean there isn't someone that 
doesn't want to do it...."