Messages in this thread | | | Date | Sat, 31 Jul 1999 09:44:08 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: New kernel/resource.c |
| |
On Sat, 31 Jul 1999, Geert Uytterhoeven wrote: > > In that case I vote for moving the ioport_resource and iomem_resource > definition from kernel/resource.c to a machine/architecture/bus specific file.
That was my plan, yes.
The only reason it is in resource.c is really historical - I didn't want to re-organize things, I only wanted to lay the groundwork. I'm expecting Martin Mares to finally 'fess up on his organizational changes, and I'll take a serious look at them when he does.
> Then it makes sense we create zorro_resource and sbus_resource for the Zorro > resp. SBUS bus on Amiga resp. SPARC systems.
Yup.
Note that in many cases it may actually make sense to make the native bus look like PCI even if it isn't. Most non-PCI buses still look enough like PCI from a programming perspective that it doesn't much matter, and they also tend to use a lot of chipsets that are comonly used on PCI devices. That way you get to use the drivers meant for PCI without them even necessarily being aware that they use something else.
So I'm not saying that you _have_ to change anything. I _am_ saying that if the PCI stuff is really uncomfortable and you prefer some other guise, you can do so.
A final word of warning: do not expect me to be thrilled about non-PCI addition to many common drivers. You may have to copy the driver and make your changes in a copy if you make your bus look explicitly different from PCI. I'm not at all excited about making fundamental drivers more complicated, and I will personally consider the "common" case a hell of a lot more important than some fringe bus that can't look like PCI.
Just a warning.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |