Date: Wed, 30 Sep 1998 13:51:13 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Karl Denninger <karl@Denninger.Net> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, scsi@FreeBSD.ORG Subject: Re: Long IDE probes? Message-ID: <199809301957.NAA21005@pluto.plutotech.com> In-Reply-To: Your message of "Wed, 30 Sep 1998 14:10:56 CDT." <19980930141056.A4656@Denninger.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
>On Wed, Sep 30, 1998 at 12:44:13PM -0600, Justin T. Gibbs wrote: >> >You and I both know damn well that to install you need ONLY, WORST CASE: >> > 1. A floppy that works (to boot from) >> > 2. A CDROM >> > 3. A disk >> >> You can also install off of tape, a CD-R that can look like a CDROM, >> an Optical disk, etc. etc. Sysinstal has allowed for this for some >> time. > >Uh, Justin, you have to get the bits on the media ;-) Not necessarily under FreeBSD. I once installed FreeBSD using a floppy set generated on an HP-UX machine. >The point I'm making here is that anything reasonably current in the SCSI >world will respond to an INQUIRY - at least - within specs. If it doesn't >then its broken. We should endeavor to fix that, yes, but at what price? > >Where is the line drawn? That's the issue here - we make everyone wait for >2% of users. My main concern is about system installation and tech support load. The defaults on the installation media should be extremely conservative. >Why not put this thing in the kernel config screen, and >default it to the SCSI standard values. If someone needs to tune it (we >can document that) then tune it. But for the rest of us, its a LOT faster. 1) The technology to put it in the kernel config screen is not quite there yet. This is another item for the generic "fix FreeBSD's configuration system" task that comes post 3.0R. 2) Even if you had it in the configuration screen I would still argue, from a tech support load and usability standpoint, that the default should be conservative. 3) Post install, there should be a series of options to "better tune your system". This allows you to educate the user and give them the option of experimenting with different system tweaks, while falling back to the previous settings if a failure occurs. >Follow the specs and give people a workaround if possible from the boot >screens. The kernel startup for the boot floppy already recommends that >you go through the config screens, so this is not an impossible goal by >any stretch. Wrong. Joe new user looks at the configuration screen, decides that it's too complicated, and goes with the defaults. The system doesn't see his SCSI devices. Why? He doesn't know. Maybe this FreeBSD thing is simply broken. Linux worked okay. So did NT. Hmmm. [ sound of CDROM going into trash bin ]. >> >Kvetching about how someone's 1980's scanner or ancient tape drive won't >> >come up under GENERIC on initial boot is both pointless and inappropriate, >> >given that you *know* these facts to be true >> >> I'm talking about old CDROM drives, CD-Rs and OD disks as well as tapes. > >There are very few of those which are (1) in service, Perhaps in your environment. >(2) don't respond to INQUIRY within specs after a RESET, and I am constantly amazed at the number of devices that come on the market every year that don't follow the spec. >(3) are actually needed to *boot and load*. >From a tech support standpoint, having a usable system after installation is also important. >For those which are, a parameter in the kernel config screen will allow >installation to proceed. Assuming they know that this is the parameter to change. >> Not everyone performs CDROM or network installs. Documentation exists >> for tape installs and for people that have unconnected machines at home, >> it should remain an option. > >An option, yes. But not the default. It is a supported installation method. There is no optional or default about it. >> >They don't RIGHT NOW and FreeBSD has NEVER had that as a criteria for >> >driver probe behavior. >> >> Does this mean that we shouldn't have that criteria? This is the >> criteria I used for all of the ISA probes for the new CAM drivers. > >You can't possibly get there from here, since there are dozens of >permutations and you can't know what is and isn't possible in a given >machine with a given set of boards. Win95/98 can do it on 99% of all machines. That satisfies my definition of possible. >> But all legacy SCSI devices are being supported by CAM (at least that is >> the intention barring bugs). > >Fine. Make it an option. It is a kernel option. >Again, document that devices which are non-complient may need a longer >timeout, and put that parameter in the kernel config screen. > >Don't penalize the rest of the users on every boot (many of who have NO IDEA >how to build kernels and fix this) because 2% of the users have hardware >which is non-complient with the SCSI (or IDE) standards. If we provide an option via user config to limit the SCSI delay (won't happen for 3.0R) then the people who are annoyed by the delay can experiment with lower settings without rebuilding their kernel. If you say that most users that can't build a kernel will not be able to find this option, then you've made my point about novice installs for me. Installation must be conservative as 50% of the people that install for the first time will not read the documentation until after they've completed the install, if ever. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809301957.NAA21005>