From owner-freebsd-hackers Wed Jun 10 11:08:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA02782 for freebsd-hackers-outgoing; Wed, 10 Jun 1998 11:08:00 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pau-amma.whistle.com (s205m64.whistle.com [207.76.205.64]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA02678 for ; Wed, 10 Jun 1998 11:07:26 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.8.7/8.8.7) id LAA21481 for hackers@freebsd.org; Wed, 10 Jun 1998 11:06:54 -0700 (PDT) (envelope-from dhw) Date: Wed, 10 Jun 1998 11:06:54 -0700 (PDT) From: David Wolfskill Message-Id: <199806101806.LAA21481@pau-amma.whistle.com> To: hackers@FreeBSD.ORG Subject: Re: new config Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: Terry Lambert >Date: Wed, 10 Jun 1998 17:35:53 +0000 (GMT) [Elision accomplished with wild abandon.... dhw] >> Hmm, how would you store static mappings with your model, like: >> I absolutely, always, want SCSI-Id 2 on controller 3 to be sd0 and keeping >> my root fs, like you now specify in the config file? >The hardware, you can't do anything about. The drivers, you can. For >example, the other day, a collegue was attempting to install FreeBSD >on a system with an NE2000 at a known address (the probe found it), >but at an unknown interrupt. It was possible for FreeBSD to determine >the interrupt, yet the driver wasn't smart enough. The determination >could have occurred four ways: >4) A user, using a configuration program (in this case, the > "visual" userconfig in the kernel) could do the same thing as > #3, after visually noting which hardware interrupts were not > allocated by running the BIOS setup. Then, at one reboot per > attempt, the card could be located. >The fourth was the method used, since a setup disk was unavailable. Yup. I remember, since I had a part in that (namely, implementing the role of "a user").... :-} >You have to got to bad hardware that *must* be destructively probed, >and whose destructive probe conflicts with *other* bad hardwares >destructive probing, before you can justify a device configuration >for device parameter's sake. And please note that it is NOT the case that the person (me, in this case) necessarily has any documentation for (or, in many cases, familiarity with) the hardware in question. >But what about for kernel configurations sake? >My personal opinion is that the device name should map precisely >and *invariantly* to the controller/target/LUN. That is, that >what you want to do is technically undesirable. Well... here, I'm less certain that saying that what the person who is using the machine wants to do "is technically undesirable" -- I recall supporting folks using software that has some bizarre tie-in to a specific (set of) device name(s). Now, granted, I think it's stupid to "design" software like that -- but not everyone has the luxury of always using software for which the source is available (and readily mungable). Given that, might it be worth considering "an additional level of indirection"? One possibility, for example, is to symlink a device name to a controller/target/LUN/slice, for example. Yes, this is similar to SysV; no, I'm not convinced that it's desirable to go quite as far as the SysV folks did. I just don't see much to be gained by contracting a rabid case of NIH. Of course, that doesn't address (sorry; no pun intended) the issue of how in the world the user who wants this should actually specify it. :-( david -- David Wolfskill UNIX System Administrator dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message