Messages in this thread | | | Date | Sat, 17 Apr 2004 10:45:27 +0100 | From | Christoph Hellwig <> | Subject | Re: [PATCH] sym53c500_cs PCMCIA SCSI driver (new) |
| |
On Fri, Apr 16, 2004 at 09:17:20AM -0500, Bob Tracy wrote: > Given that the driver currently supports only PCMCIA implementations, > I agree. My thinking was if someone comes up with a host adapter that > isn't PCMCIA, the SYM53C500.c file is to the sym53c500_cs driver what > the qlogicfas.c file is to the qlogic_cs driver, that is, core functions > that could support multiple types of host adapters. The logic to > handle the different types of adapters isn't there, and I don't know > that it ever will be (else, it's probable that someone would have > written the Linux driver long before now). However, after baring my > ignorance to the world and saying I was unaware of non-PCMCIA > implementations, I found a FreeBSD driver for the NCR 53c500. Never > say "never," I guess... Your opinion counts for much, but you're the > only person I've heard from. Is there a consensus I should forget > about the non-PCMCIA cases?
I'd suggest to keep it as simple as you can for the time beeing. If we ever find a user with a ISA or whatever variant he can split it out. And such a split would work a little different from what you did now.
> > - the driver doesn't even try to deal with multiple HBAs > > Guilty as charged. Functionally, there's nothing in the driver I > submitted that wasn't in the original. Suggestions welcome... Which > of the existing PCMCIA SCSI drivers do a proper job of handling > multiple host adapters in your opinion? I'll try to adapt that code to > fit this driver. If I have to "roll my own" from scratch, I'm probably > in over my head.
It looks like nsp_cs at least tries to :-)
> > - your detection logic could be streamlined a little, e.g. the request/release > > resource mess > > I'll see what I can do. > > Although I touched on it above, by way of apology/explanation, the goal > for the initial port was to replicate the functionality I already had in > older kernel versions. It appears I faithfully replicated the > deficiencies of the old driver as well :-). Again, thank you for the > feedback.
Hey, you don't need to apologize. Anyt 2.6 driver is better than none and your looks quite okay from the functional standpoint. We just need to have a little higher bars for new drivers as we already have lots of maintaince overhead for old and sloppy written drivers.
- 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/
| |