Hi,

Lennart Sorensen wrote:
quoted text
> Yes.  After all you would quickly see a problem if you built a kernel
> with all the IDE drivers built in, which some people do.  In that case
> ide generic is always activated last and anything bad that would happen
> with loading a module would happen built in too.

Yeah, pick the right configuration.  You can make it malfunction.

quoted text
> I think it is the wrong place to worry about problems.  If a native
> driver takes control of a chip, it is that drivers responsibility to
> reserve any relevant ports on that chip sufficiently to prevent another
> driver from messing with it that doesn't know anything about that chip.
> If the native driver doesn't load at all, then ide-generic ought to try
> and drive the chip if it has legacy ports.

I'm not too sure whether that will be always possible and I'm less sure 
we'll get enough test coverage over this kind of stuff.

quoted text
> So my opinion is that making life easy to those machines with legacy ide
> ports is a good thing, while trying to be overly paranoid about one
> driver potentially hitting a bug in another driver is just silly.  Why
> couldn't two native ide drivers potentially go looking for the same
> ports too?  Are you sure no native driver uses the legacy IDE port
> numbers to control a chip in native mode?  Finding bugs is good since
> then they can be fixed.  Trying to prevent hitting bugs (which shouldn't
> be there in the first place) doesn't seem useful.

Yeah, theoretically, you're right.  The problem is that what breaks when 
things go wrong.  If you don't probe generic ports by default, harddisks 
won't be detected on some legacy systems but you can always prompt the 
user about loading the generic driver.  If you probe generic ports by 
default, when things go wrong, you break modern machines in an 
unrecoverable (w/o reset) way.  I'd rather choose bothering the user on 
legacy machines.

thanks.

-- 
tejun
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/