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/