From owner-freebsd-hackers Sat Apr 29 14:17:40 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA16064 for hackers-outgoing; Sat, 29 Apr 1995 14:17:40 -0700 Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA16058 for ; Sat, 29 Apr 1995 14:17:32 -0700 Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.8/8.6.6) id QAA04294; Sat, 29 Apr 1995 16:14:09 -0400 From: "House of Debuggin'" Message-Id: <199504292014.QAA04294@skynet.ctr.columbia.edu> Subject: RE: Boot message rampage To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 29 Apr 1995 16:14:04 -0400 (EDT) Cc: hackers@FreeBSD.org In-Reply-To: <13702.799154490@time.cdrom.com> from "Jordan K. Hubbard" at Apr 29, 95 04:21:30 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 9135 Sender: hackers-owner@FreeBSD.org Precedence: bulk They say this Jordan K. Hubbard person was kidding when he wrote: [Jordan submits a proposal for boot message reoganization] > 1. Eliminate all but the "found" messages, allowing you to make kernels > with additional device support that aren't as chatty as the ones now. > When you boot a generic kernel on a given machine, it should show you > what it finds there and nothing more. If you need more information > about what's being searched for, what's being found and what's not being > found, then I think that's a special circumstance and you should boot > with -v. Actually, I never thought of getting rid of the 'not found' messages. I'm happy with them either way. However, it should be noted that I don't tend to leave the GENERIC kernel in place on my systems for very long. My way of keeping the 'not found' messages from bothering me is to config a custom kernel that only includes support for devices that I have. (Actually, getting rid of the probe failure messages isn't my primary motivation: it happens that many of the device probes take a while to time out, and I don't like waiting for my system to boot. :) > it should just work out of the box! In the exceptional cases where it > doesn't, the user can boot with -v. It would look neater, but I wouldn't worry too much over this. Best to concentrate on the other messages, I think. > 2. Carefully examine each and every probe message and attempt to regularize > it to some standard form, e.g.: [snip] > sc0: Syscons Console Driver, port 0x60-0x6f, irq 1 [VGA color] on ISA. > sc0: [16 virtual consoles] > ed0: General Ethernet Driver, port 0x280-0x29f, irq 15, ioaddr 0xd8000, iosize 16384 on ISA. > ed0: [address 00:00:c0:58:99:72, type SMC8416C/SMC8416BT (16 bit)] > sio0: Serial IO Driver, port 0x3f8-0x3ff, irq 4 [type 16550A] on ISA. > fdc0: Floppy Controller, port 0x3f0-0x3f7, irq 6, drq 2, [NEC 72065B] on ISA. > fd0: on fdc0, [1.44MB 3.5in]. Aaahhh!! Nooooo!!! I said make the messages more consistent, I didn't say you should rewrite them in your own, twisted, Perl-generated image! :) Please, lose the 'Syscons Console Driver,' and 'General Ethernet Driver,' and 'Serial IO Driver' stuff! This irritates me far more than anything we have now! > This is just off the top of my head, and already I don't like it, but > it's at least orthogonal. The top of your head is orthogonal? :) > The biggest headache are attached devices > like fd0 here. I'm not sure how best to deal with them. > Maybe something > like ": on , [optional attributes]". fd0, just like wd0 and sd0 is a drive attached to a controller at a particular unit number. It should be more like: at unit : (See example below.) 'Naughty bits' can be some device-dependent info, which should be consistent for similar devices. Disk drives should list capacity in megabytes and geometry. (Or, in the case of SCSI disks, number of sectors instead of geometry, since it's been argued to death that the geometry reported for SCSI disks is generally not useful.) All of these are optional since they may not apply in some cases. Note that if you jiggled your kernel config a bit, could conceiveably wind up with: fd1 at fdc0 unit 0 which looks bass-ackwards, but should otherwise work. This is not a bug, it's a feature. Lookit, here's an example of what I would consider ideal boot messages: FreeBSD BUILT-19950428 #0: Fri Apr 28 11:36:14 EDT 1995 root@nakedgun.ctr.columbia.edu:/usr/src/sys/compile/NAKEDGUN CPU: 90-MHz Pentium 735\\90 (Pentium-class CPU) real memory = 16384000 (4000 pages) avail memory = 15089664 (3684 pages) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: sio0 at 0x3f8-0x3ff irq 4 on isa sio0: sio1 at 0x2f8-0x2ff irq 3 on isa sio1: lpt0 at 0x378-0x37f irq 7 on isa lpt0: lp0 at lpt0 lp0: psm0 at 0x60-0x63 irq 12 on motherboard fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: fd0 at fdc0 unit 0 fd0: <1.44MB 3.5in, 80 cyls, 2 hds, 36 S/T, 512 B/S> fd1 at fdc0 unit 1 fd1: <1.2MB 5.25in, 80 cyls, 2 hds, 30 S/T, 512 B/S> wdc0 at 0x1f0-0x1f7 irq 14 on isa wd0 at wdc0 unit 0 wd0: wd1 at wdc0 unit 1 wd1: ahc0 at 0x1000-0x10ff irq 11 on eisa slot 1 ahc0: = Rev E, 16 SCBs> ahc0: Probing channel A ahc0: target 0 synchronous at 10.0MB/s, offset = 0x19 sd0 at ahc0 target 0 unit 0 sd0: ahc0: Probing Channel B ix0 at 0x300-0x30f irq 10 maddr 0xd0000 msize 32768 on isa ix0: npx0 on motherboard npx0: root on sd0a fstype ufs Notes: - Don't print more than one line of CPU information unless booted with -v. Once we go multi-processor, then we could do cool things like: cpu0: 90-MHz Pentium 735\\90 (Pentium-class CPU) cpu0: cpu1: 90-MHz Pentium 735\\90 (Pentium-class CPU) cpu1: - The ethernet adapter messages are a bit of a sore point for me. Typically you don't see vendor information displayed for ethernet interfaces since they tend to be built into workstation class (or larger) machines. But since not all PCs have built in ethernet and since there are a large number of ethernet adapter vendors, it's probably a good idea to do it this way. - As Peter has already noted, there are problems involved in generating SCSI probe messages in the way I've suggested. I agree and I have no idea how to fix it, at least not when using a kernel config that doesn't 'wire down' devices to particular targets. (Current opinion is that the 'assign numbers automatically to SCSI devices in the order in which we find them' behavior is the default, and the 'wire down devices to specific busses/targets' behavior is a special case. I happen to think it should be the other way around. This might be because I'm a control freak; I want to tell the system how I want the devices arranged, I don't want it to tell me. I'm also accustomed to doing it that way with SunOS.) It seems to me though that in a configuration where you have wired down the devices and already know where they're supposed to end up by the time you've probed them, this should be a problem. - The ahc driver prints out more than just two lines in my example, but I feel this is justified by the fact that it's something of a special case; since it has two channels, you'd sort of like to know when it's probing them. The 'target 0 synchronous at 10.0Mb/s' message probably ought to go away. I think SunOS used to print messages like this in 4.1.2, but I'm pretty sure they ditched them by the time they reached 4.1.3. So long as all the SCSI controllers that generate such messages use the same format, I could probably live with them. - The lp0 TCP/IP device is a weird one because it's a driver implemented within another driver. It's not really a device that's attached to the printer port, it *is* the printer port. This is why the message says 'lp0 at lpt0' and nothing else (there is no unit number). - We don't print any secondary information for psm0. There are no vendor strings for PS/2 mouse controllers, or for PS/2 mice for that matter. Still, if someone wanted a line that said something like 'psm0: ' I wouldn't complain too loudly. - I have no idea what exactly should be done with the PCI probe messages, except that they should probably try to follow the format of the others if possible. Ditto for the eisaconf stuff too. - I don't have a kernel with sound support handy, but now that we have proper config options for the sound driver, it should follow this pattern too. - I like angle brackets for historical reasons. I don't like braces. 'Nuff said. > Assuming that the syntax can be agreed upon, is that enough detail to > go on? I'd prefer not to debate this for a long time or we will end > up doing what we usually end up doing at the end of long debates: Nothing. > > Jordan I don't want to beat it to death either, but I also don't want to be stuck with your proposed syntax. :) -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~~~~ FreeBSD 2.1: "We can kick your operating system's ass!" ~~~~~~~~~~