On Sat, 23 Oct 2004, Garance A Drosihn wrote: > So, what *do* we want, and what things do we need as we expand our > support to somewhere between six and ten architectures? Good question... I have a few ideas of my own. I will share them once I have thought them completely through. > I do not know how I would break up *everything*, but let's take a > few easy cases. Say, categories like SCSI or Firewire. Well, SCSI ends up being a messy case... See below. > I think it is obvious that GENERIC should default to including > support for all scsi controllers, just so a person can get up and > running on any hardware that we support. But when it comes time to > customize a kernel, what will a person want to do for any category? > Most likely, they want one of two things: > 1) Turn off *all* scsi, because they know they have no > scsi card at all. This will break USB CF readers, pendrives and Firewire SBP2 storage devices, unless by "*all* scsi" you're just refering to "all scsi controllers". > 2) Turn on the scsi card that they have, but turn off all > other scsi cards. > > For either case, what I would like is to duplicate the GENERIC kernel, > and then have to modify only one single line to get what I want (one > line per category, that is). Maybe something like: > 1) SCSI OFF > 2) SCSI ON,ahc > > If I know I have ahc (which I can read from dmesg), then I should not > need to learn the full list of possible SCSI controllers. I just need > to know "I have one scsi controller, and it looks like that is called > 'ahc', so I will turn on that specific controller and trust that all > other SCSI controllers will be turned off". > > How does that sound? This sounds great! I for one would love to not have to comment out 30-some odd controllers just to keep my kernel config in sync with GENERIC! So, how do we plan on handling devices that use scsi emulation? Do we silently enable da (And possibly scbus)? :-) Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ >Received on Mon Oct 25 2004 - 04:24:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:19 UTC