Date: Sat, 29 Apr 1995 16:14:04 -0400 (EDT) From: "House of Debuggin'" <wpaul@skynet.ctr.columbia.edu> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@FreeBSD.org Subject: RE: Boot message rampage Message-ID: <199504292014.QAA04294@skynet.ctr.columbia.edu> In-Reply-To: <13702.799154490@time.cdrom.com> from "Jordan K. Hubbard" at Apr 29, 95 04:21:30 am
next in thread | previous in thread | raw e-mail | index | archive | help
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 "<dev><unit#>: on <controller>, [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:
<dev><unit#> at <controller><controller#> unit <unit#>
<dev><unit#>: <vendor string, device type, revision, naughty bits>
(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: <VGA color, 16 virtual consoles, flags=0x0>
sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: <type 16550A>
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: <type 16550A>
lpt0 at 0x378-0x37f irq 7 on isa
lpt0: <Interrupt-driven port>
lp0 at lpt0
lp0: <TCP/IP capable interface>
psm0 at 0x60-0x63 irq 12 on motherboard
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: <NEC 72065B>
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: <QUANTUM LP52A 950509105, 49MB, 751 cyls, 8 hds, 17 S/T, 512 B/S>
wd1 at wdc0 unit 1
wd1: <WDC AC140, 40MB, 980 cyls, 5 hds, 17 S/T, 512 B/S>
ahc0 at 0x1000-0x10ff irq 11 on eisa slot 1
ahc0: <Adaptec 274x Twin Channel, aic7770 >= 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: <SEAGATE ST31200N 9022, 1006MB, 2061108 512-byte sectors>
ahc0: Probing Channel B
ix0 at 0x300-0x30f irq 10 maddr 0xd0000 msize 32768 on isa
ix0: <Intel EtherExpress16, address 00:aa:00:a1:97:2d>
npx0 on motherboard
npx0: <INT 16 interface>
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: <GenuineIntel, stepping=#, features: FOO,BAR,BAZ>
cpu1: 90-MHz Pentium 735\\90 (Pentium-class CPU)
cpu1: <GenuineIntel, stepping=#, features: FOO,BAR,BAZ>
- 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: <PS/2 mouse interface>' 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!" ~~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504292014.QAA04294>