Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Apr 1995 04:21:30 -0700
From:      "Jordan K. Hubbard" <jkh@time.cdrom.com>
To:        "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>
Cc:        hackers@FreeBSD.org
Subject:   Re: What I'd *really like* for 2.0.5 
Message-ID:  <13702.799154490@time.cdrom.com>
In-Reply-To: Your message of "Fri, 28 Apr 1995 23:50:47 PDT." <199504290650.XAA08734@gndrsh.aac.dev.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> The ``not found'' messages issue was debated and decided shortly after it
> was implemented.  The major reason for keeping it around is that you
> know the kernel looked for the device, you know at what address it tried

I'm well aware of why it was decided to keep it, having been there
during the debates, but this doesn't mean that I agreed with the logic
then or now.

> I do mind to some extent if you go on a ``message reform rampage'' with
> out a clear statement of just what it is you are going to do.

Fair enough:

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.

   Nate has argued that "it's valuable to know what the kernel didn't find"
   and I strongly disagree.  It's valuable to know this WHEN YOU'RE HAVING
   TROUBLE AND IT'S NOT FINDING STUFF YOU *WANT* IT TO FIND, and for every
   other case it's just NOISE.  I would hope that as FreeBSD's device
   support gets better, and it's already fairly good (for a PC based UN*X,
   anyway), we'd have less and less need to have people do anything special;
   it should just work out of the box!  In the exceptional cases where it
   doesn't, the user can boot with -v.

   It's also foolish to debate this on the merits (or lack thereof) of our
   documentation.  I can readily suggest a number of truly loathsome
   hacks that would easily compensate for some aspect of our system
   being poorly documented, but it wouldn't make them right or desirable.

2. Carefully examine each and every probe message and attempt to regularize
   it to some standard form, e.g.:

	<devname><unit#>: <description>, port <port>, irq <irq>, drq <drq>, ioaddr <ioaddr>, iosize <iosize> [optional attributes] on <bus>.
	[<devname><unit#>: [optional information]]

   The goal being to get principle probe messages on one line again and
   to display the various parameters using the SAME naming conventions used
   in userconfig to minimize confusion.  Some examples:

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].

This is just off the top of my head, and already I don't like it, but
it's at least 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]".

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13702.799154490>