Date: Wed, 11 Aug 1999 12:47:31 -0400 (EDT) From: "Matthew N. Dodd" <winter@jurai.net> To: Warner Losh <imp@village.org> Cc: Peter Wemm <peter@netplex.com.au>, Cameron Grant <gandalf@vilnya.demon.co.uk>, multimedia@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: it's time... Message-ID: <Pine.BSF.4.10.9908111236440.14648-100000@sasami.jurai.net> In-Reply-To: <199908111603.KAA17583@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Aug 1999, Warner Losh wrote: > Then we disagree. There are several scripts floating around that use > them for purposes where there isn't a kernel interface... It would be > ideal if there were interfaces for all this info, but there isn't > always. Fine. Due to flux in the bus-system between versions, probe/attach information is essentially a non supported interface for gathering this data. If you do wish to gather it from this source its up to you to DTRT. If you dislike this then your input on a standard interface to this information would likely be of use. > : An interface to query the resource manager directly is likely to be a > : better solution to your problem. > > Well, only kinda. That was one example. The other example is finding > out what the ide driver thought the disk geometry of a disk was... If that information needs to be presented I see no reason why drivers can't do some magic and make /kern/foo/wd0/geometry spit out the right thing. Granted, this is more complex, but depending on boot messages for this information is setting yourself up for problems. > : Besides, if your perl skills aren't able to cope with getting all 'fooX:' > : lines, and stripping out the 'fooX:' bits before parsing then you have > : other problems. > > Hah! You presume too much. None of these scripts are written in > perl, so the size of my perl schl*** isn't at issue here :-) You also > assume that the wrapping would be of the form fooX:. FreeBSD's boot > messages aren't consistant about this right now, witness the > difference between isa and pci devices: > > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > > vs > > ahc0: <Adaptec 2940 Ultra SCSI adapter> irq 10 at device 16.0 on pci0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > > The "proper" way to do this would be > > sio1 at isa0 port 0x2f8-0x2ff irq 3: type 16550A > ahc0 at pci0 irq 10 device 16.0: <Adaptec 2940 Ultra SCSI adapter> > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs Incorrect. The device name should be separated from the rest of the line by a ':'. > if you must introduce wrapping. Each phrase should either fit on the > current line or be bumped to the next line. However, what is a line? > > Also, I use "proper" in quotes because others will reasonably differ > with the exact details... Indeed. But you've still prooved my point that the probe/attach messages are an unsupported source for such information. > : Correct, but the nature of the kernel probe/attach messages is to convey > : information in a readable, consistent, useful manner. > > Agreed. However, what's magical about 80 columns? My editors go out > to 180 sometimes. The console can easily be placed into a mode where > it is > 80. This is especially true for the serial console where it > might be connected to a 132 column printer. In the beginning was the punch card... > : If we didn't want pretty line wrapping we'd all be using linux and have > : stupid stuff like copyright messages as well. :) > > Don't even get me started on linux' boot messages. :-) > > I happen to like the stark elegance of the OpenBSD/NetBSD boot > messages. Here's the entire dmesg from the boot of my rPC44 MIPS > machine when booted under OpenBSD. > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-1999 OpenBSD. All rights reserved. > http://www.OpenBSD.org > > OpenBSD 2.4-current (IMP-PCCARD) #37: Mon Feb 1 13:28:06 MST 1999 > imp@local-service.village.org:/home/imp/src/sys/arch/arc/compile/IMP-PCCARD > real mem = 32235520 > avail mem = 27754496 > using 419 buffers containing 1716224 bytes of memory > mainbus0 (root) > cpu0 at mainbus0: MIPS R4400 CPU Rev. 4.0 with MIPS R4010 FPC Rev. 0.0 > L1 Cache I size 16kb(16 line), D size 16kb(16 line), direct mapped. > L2 cache doesn't snoop uncached cpu accesses. > isabr0 at mainbus0 > isa0 at isabr0 isa_io_base 0xb0000000 isa_mem_base 0xa0000000 > com0 at isa0 port 0x3f8-0x3ff irq 4: ns16450, no fifo > com1 at isa0 port 0x2f8-0x2ff irq 3: ns16450, no fifo > wdc0 at isa0 port 0x1f0-0x1f7 irq 14 > wd0 at wdc0 drive 0: <SAMSUNG WN321620A (2.16 GB)> > wd0: 2060MB, 4186 cyl, 16 head, 63 sec, 512 bytes/sec, 4219488 sec total > wd0: using 16-sector 16-bit pio transfers, lba addressing (109KB cache) > clock0 at isa0 port 0x70-0x6d5 irq 0: mc146818 or compatible > pcprobe: reset error 1 > pc0 at isa0 port 0x60-0x6c5 irq 1: color > joy0 at isa0 port 0x201: joystick not connected > ed0 at isa0 port 0x300-0x31f irq 5: address 00:00:1b:1e:52:a7, type NE2000 (16-bit) > boot device: wd0. > root on wd0a > rootdev=0x400 rrootdev=0x1200 rawdev=0x1202 > > Where OpenBSD has > > com0 at isa0 port 0x3f8-0x3ff irq 4: ns16450, no fifo > com1 at isa0 port 0x2f8-0x2ff irq 3: ns16450, no fifo > > FreeBSD we has > > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 16550A > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > sio2: configured irq 5 not in bitmap of probed irqs 0 > sio3: configured irq 9 not in bitmap of probed irqs 0 > > which is much more verbose. The entire boot process (including rc > output) fits on the 48x132 mode that my rPC/44 comes up in. With the > same config on FreeBSD, the kernel messages it wouldn't even fit, let > alone the rc output. I don't think its unreasonable to have multiple levels of verbosity in the probe/attach messages. level meaning 0 no probe/attach messages for bus/device printed 1 device name/bus attachment point 2 bus/device resource reservation announcements 3 device specific versioning/level/other messages > : At some point all of the boot messages should be wrapped by 'if > : (bootverbose) { ... }' anyway. > > No! At some point they should use a facility similar to solaris/sysv > where they don't display, but do make it into the dmesg buffer... The effect is the same. At some point we need to provide output only on error, like the rest of unix. I submit that I like verbose boot messages and want them to be well formatted at the same time as I spend a lot of time yanking cards in and out of systems and need to make sure that my probe/attach routines DTRT. Normal users are likely to enjoy the graphical splash screen more than the frightening spew of boot messages. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908111236440.14648-100000>