--1y6imfT/xHuCvpN0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 13, 2003 at 03:23:10PM -0700, Greywolf wrote:
> Thus spake Bill Studenmund ("BS> ") sometime Today...
>=20
> BS> No, it won't. Maybe I cut too much context, but the scenario describe=
d was
> BS> you have "com0" found but in a message-pending state (we haven't gott=
en to
> BS> its place in the order yet, whatever that order is). You are now prob=
ing
> BS> sd0, and _it_ has a hardware issue that causes the kernel to not boot.
> BS>
> BS> Since sd0 was the next thing to print, and that's where we had the ke=
rnel
> BS> issue, I don't see how "com0" not being mentioned will matter. The pr=
oblem
> BS> is with sd0 and it should be obvious that it's with sd0. :-)
>=20
> Why not just line-buffer the device messages and be done with it?

Because we then are running races on dmesg output.  Yes, we eliminate the=
=20
issue of lines getting chopped up, but we still have the issue of lines=20
moving around in the output depending on exactly how long things take.

Our security and system monitoring scripts like to diff the boot dmesg of=
=20
today with last boots (or a "blessed" boot) to note differences. I think=20
this is a good thing to do. If we let lines wander around, we can generate=
=20
false positives from these scripts. I also think that the general idea of=
=20
a consistent message stream for at-boot hardware is a good thing, and=20
should be retained.

Take care,

Bill

--1y6imfT/xHuCvpN0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/iy2YWz+3JHUci9cRAnrCAJsGirRNmCYZvHYgkv1Viqnj18KdHgCdFLJ6
IMf+emIjEhwkUNb2cH912hQ=
=C2e9
-----END PGP SIGNATURE-----

--1y6imfT/xHuCvpN0--