From owner-freebsd-current@FreeBSD.ORG Sat Oct 27 22:05:19 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7C7F16A4D4 for ; Sat, 27 Oct 2007 22:05:19 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9335A13C4AA for ; Sat, 27 Oct 2007 22:05:19 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp007-s [10.150.69.70]) by smtpoutm.mac.com (Xserve/smtpout018/MantshX 4.0) with ESMTP id l9RM5I2h013518; Sat, 27 Oct 2007 15:05:18 -0700 (PDT) Received: from [172.24.104.109] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp007/MantshX 4.0) with ESMTP id l9RM5FGK008112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2007 15:05:16 -0700 (PDT) In-Reply-To: <20071027212420.EC7F94500E@ptavv.es.net> References: <20071027212420.EC7F94500E@ptavv.es.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28D8C5EF-8BAB-433D-A6E3-25B2A40B9BD1@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 27 Oct 2007 15:04:40 -0700 To: Kevin Oberman X-Mailer: Apple Mail (2.752.2) Cc: John-Mark Gurney , current@freebsd.org Subject: Re: New-bus unit wiring via hints.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2007 22:05:19 -0000 On Oct 27, 2007, at 2:24 PM, Kevin Oberman wrote: >> From: Marcel Moolenaar >> Date: Sat, 27 Oct 2007 13:57:25 -0700 >> >> >> On Oct 27, 2007, at 12:40 PM, Kevin Oberman wrote: >> >>>> I'm not mandating anything. I'm merely pointing out how >>>> reality has changed and that it's important to adapt, >>>> adopt and improve... >>> >>> "Reality has changed"? Yes, it has, at least a bit, but not to the >>> point where we want to confuse serial ports. >> >> Are you saying that "we" should accept reality's change >> only for as far as it doesn't confuse "us" ??? > > Just in case I don't understand the issue, feel free to correct me, > but > it sounds like you are saying that there will not be a clear link > between the serial port (sio) number and the port marked '1' on most > systems. If I am wrong about this, please tell me and I climb back > under my rock. That is not what I'm saying. What I'm saying is: If the firmware tells the OS that the port marked "1" on the back corresponds to a UART that has a base I/O port address of 0x2e8, then who are we to disagree and demand that it should be 0x3f8? You rightly point out that what it really boils down to is how devX maps to a port on the back or front of the machine. This mapping should not change gratuitously. Device wiring achieves that. >>> In my case, I am only talking to a data logger and not actually >>> controlling something, but I should not have to worry about having >>> a port >>> name change or finding that _UID1 was no longer the same device if I >>> move to a new mother board. >> >> That's unrealistic. If you change the underlying hardware >> configuration you cannot expect that it doesn't have some >> sort of effect on the system. Wiring is about making that >> effect as small as possible, not about having FreeBSD do >> its own thing with disregard of the hardware. > > If I really change the configuration, then I should expect changes in > operation. But upgrading to a new system or motherboard where the port > marked '1' is suddenly not sio0 is not a configuration change, in my > view. Why not? You replace a mainboard. You really replaced the whole computer, because there's no concept of chassis port numbers in FreeBSD. All we know about the hardware is what is on the mainboard. > The new system has, to the typical user's eyes, the same > configuration. Yes. this means there's a gap between what the user sees (the chassis) and what FreeBSD sees (the mainboard). As long as the mainboard is designed for the chassis, that gap is mostly non-existent or insignificant and what the firmware tells the OS is what you see on the back (or front). Otherwise, all bets are off... > This gets even worse in some cases. For example, many newer mobos > have a > single serial connector on the back and another available only as a > header connector on the board. (I have a lot of such systems scattered > all over the country.) I would be extremely upset if the '1' port, > configured as the console was to become sio1 and I could not access > the > system from the terminal server. I can imagine. Not the best way to program a firmware. Then again, if the mainboard was not designed for the chassis, and it is actually programmed correctly for the targeted chassis then the fault is not with the firmware. Luckily, chassis makers and mainboard makers tend to standardize on certain layouts, so this hardly ever is a problem. But, again, we as OS makers should not make the mistake of assuming too much. Only then will we actually play along and end up doing the right thing. Hints can only do harm in that case, which basically means that hints can only do harm because we don't need hints to do the right thing... -- Marcel Moolenaar marcelm@juniper.net