On Mon, Jan 26, 2009 at 02:28:59PM -0500, Brian Thompson wrote:
In my opinion that would also be a satisfactory solution. I believe it would complicate things though for those who need to use the dmfe module along with that particular PCI ID (possibly DEC alpha users?). It would be better if we can figure out a way to disable the dmfe module for that PCI ID on sparc without affecting other architectures.
Well, the preprocessor seems to be the right tool here. #ifndef __sparc__ or #ifdef __alpha__ are distinct possibilities.
That's true from an technical electrical perspective but there's also "supported" NICS and then there are NICS who's support on sparc was an afterthought. The issue mainly comes into play when trying to do a "boot net" from OBP, etc...
This is true, but also a red herring. Once Linux boots, whether "boot net" works or not is irrelevant, since there's already a kernel (and initramfs, if needed) loaded. I will agree that some people may be more likely to purchase cards that support OBP configuration, but those are by no means the only cards used in sparc machines.
I'm all for adding and keeping support for as many different NICs as possible but not when it causes a problem for native on-board ethernet.
Debian could ship a default configuration that blacklists dmfe on sparc, as well. Or it could be documented in the release notes that users of those machines will need to blacklist dmfe manually. udev does seem to honor blacklists when loading modules, and those people that aren't using udev will likely know not to load those conflicting modules.
Maybe the solution is somewhere in the middle... Seems the ideal situation would be for the dmfe kernel module to be built and installed on sparc by default but not enabled/mapped. That way someone who does want to use it would only have to make some minor text file changes instead of having to actually compile the module, but again, I'm not sure if there's a way to do that without affecting other architectures.
I think it's quite possible to do any of these things. I'll leave it up to the Debian kernel team and the sparc porters to choose what is most appropriate for the situation, as long as both modules are built and installed on all machines that can support both cards. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Attachment:
signature.asc
Description: Digital signature