Date: Sat, 08 Apr 2006 13:41:35 -0600 From: Scott Long <scottl@samsco.org> To: Mike Meyer <mwm@mired.org> Cc: hackers@freebsd.org, Ceri Davies <ceri@submonkey.net> Subject: Re: Using any network interface whatsoever Message-ID: <443811EF.2020509@samsco.org> In-Reply-To: <17463.65076.117616.563302@bhuda.mired.org> References: <C05CAC06.C0BD%ceri@submonkey.net> <20060407225742.GA21619@odin.ac.hmc.edu> <20060407230247.GH16344@submonkey.net> <4437C9F6.5000008@samsco.org> <17463.65076.117616.563302@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Meyer wrote: > In <4437C9F6.5000008@samsco.org>, Scott Long <scottl@samsco.org> typed: > >>Well, the real question is why we force the details of driver names onto >>users. Network and storage drivers are especially guilty of this, but >>tty devices also are annoying. > > > Because Unix has always made the hardware details available to > administrators. Times have changed so that users now need to do things > that used to be restricted to administrators. > > This historical behavior is a *good* thing. If all devices of type > "foo" are just named "foo" and assigned numbers by the system, then I > have no control over the names. If I don't care which is which, this > isn't a problem. If I do care - for instance, I want to distinguish > between the ethernet interface that's on the internet and the one > that's on my LAN, or I want root to be on the disk with the root file > system on it - then this is a PITA, because every time I add hardware > to the system, or re-arrange the cards in the cage, or similar things, > I risk breaking the system configuration. If the device names are > completely determined by the hardware settings, then this doesn't > happen. > > Real world examples of this type of breakage include a FreeBSD 4.x > system with SCSI disks that failed to boot when a USB mass storage > device was plugged into it, and a Solaris system that started swapping > on it's Ingres raw database partition after a disk was added. > > If a system is meant for desktop use where you typically have at most > one of anything, then hiding the names from the users is a good > thing. In a server environment, where you may have multiple instances > of several different device types, then being able to easily tell > which is which is a good thing. > > <mike You're argument here doesn't really make sense. Youre' saying that instead of /dev/da0, we should have /dev/HITACHI-HUS103073FL3800-SA19-B0T1L0, and instead of em0, it should be em0-192.168.254.199-24-192.168.254.1-192.168.254.255, right? That way all the information is present and there is no chance of mixing up devices. I'm not saying that we should get rid of the device information. I'm fully happy making it available to top layer applications. Administrators definitely need the information to make good decisions. But the information isn't always needed, and it does make simple management tasks harder. It also adds complexity that can lead to problems. Why when I add a RAID driver do I also need to hack up sysinstall so that it'll recognise the RAID devices? This is 2006, not 1976! The computer should be helping us in administration tasks, not hiding behind inconsistent and obscure names. Now, for your specific case of SCSI, it is possible to wire down device assignments by the administrator. It's been documented how to do this in man pages and kernel config files, most recently by me personally, for years. The flaw is that it still requires specific operator intervention to make work. That's where things like volume labels come in. Does a sysadmin care about the low-level device name for a drive on a Windows or Mac system? Does he even know without taking a deep look inside the system? Does not knowing it make it any less possible to easily and reliable manage and control the hardware? It's all done through human-readable labels that are easy to work with. The low level information is still available when needed, but it's not the primary means of control. I think that's fine; it strikes the balance between control and ease of use that I'm looking for. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?443811EF.2020509>