In message <Pine.NEB.4.05.10001202059210.26938-100000@audrey.Ivy.NET>,
Miles Nord in writes:

>Could you (re)post this please?  I couldn't find it easily.

freebsd serial console:   http://www.freebsd.org/handbook/x12232.html



>You're right that I didn't read the URL's you posted,

[...  reasonable reasons... ]

> Hopefully others with a stronger commitment to
>Intel technology gave them a look.

Maybe.  A quck Google search shows that NetBSD users were inquiring
about EMP and Intel "server" motherboards nearly a year and a half
ago.  I didnt find any responsive replies, tho'.  I find it hard to
believe I'm the first NetBSD user to seriously investigate this,
but perhaps I am.


>> 	``The bootblocks are perfect.  Our bootblocks already do
>>         everything anyone needs. You're just too stupid to understand
>> 	that you are trying to do the wrong thing. Here's what
>> 	you should be doing instead!''
>
>Yes, that is pretty much exactly what I believe.  Except I would probably
>say ``diabolically misled'' rather than stupid.

Then you must have a very different model of console usage, or system
usage and management, than the one I have for the serial-console
machines.

Here's something I wrote to David Brownlee:


}But I am not worried about install issues.  (Those
}I would do with a VGA screen and keyboard, with the machine by my
}desk).  I am worried about remote manageability. My email server was
}down for nearly 3 weeks over Xmas: the machine is in a wiring closet
}at Stanford, my advisor took the wiring-closet key with him to SOSP,
}we only have one key, the paid sysadmins with keys were on
}vacation, and finally my electronic key to the building timed out on
}Jan 1. (The wiring closet key is mechanical.) And we
}still dont know what caused the crash.


}when I think what "serial console" is for, I think 'managing machine
}behind locked door for which you no longer have the key'.  That's how
}co-location at ISPs works, too, from what I hear. (No wonder Allen
}Briggs wants the same thing, if he's into web-hosting).  That's very
}different from a lab-style environment. I am sure its possible to
}design serial-console support that works well for both. What we have
}works well for the lab or debugging.  (Matthias says so, and i beleive
}him).  But for the ISP style, what we have is psychotic: I looked at it,
}and literally could not understand why anyone would do it that way.


>NetBSD:  it sucks less.

Sorry. Nope.  For physically-secure server farms with
difficult-to-arrange physical access, and very rare physical visits
(e.g., hardware upgrades), NetBSD sucks a little more.

Really truly, it does. I tell you three times.



>I haven't been offended by anything you've said so far, and hope the same
>holds true for you.  If not, well, uh, i'm sorry.  Hopefully everyone
>understands I tend to hold extreme opinions--please don't take me too
>seriously.

Okay.


>I think part of the point here is that it's extremely difficult (but not
>necessarily unadviseable) to productively disagree with programming
>decisions when you're writing on a list where the authors hang out.  It's
>likely to be taken personally, and what's worse is that they might be
>tempted to argue with you rather than writing more code for us!  So,
>you're definitely in a difficult spot.

I can understand that.  I am sure Matthias (and whoever else worked on
bootblocks and serial consoles) has done a good job at what _they_ saw
as being needed.  

OTOH, I invite Matthias or anyone else to think hard about, say,
someone putting boxes in a rack in an ISP, and which makes more sense:
what we have nor, or what I've been suggesting.  Matthias (and other
committers, like David Brownlee) have done a really great job at
trying to get the tools we have to solve my problem.  But the
tools  just dont fit.

My claim is that an alternative, _two-headed_ consoles, or
wye-consoles-- where console output goes to both a serial port and a
display screen, and input is accepted from either a serial port or a
keyboard -- is *better* for the lab scenario Matthias describes than
what we have now.

Okay?

>Recently, your suggestions have become more specific, sensical, and
>perhaps useful than what I originally thought.  The problem for me is that
>I want to make sure you don't I don't want to see years of trial-and-error
>history with lots of subtle implications bent around this one Task you're
>trying to do.

Mike, that I do find offensive.  Just how long do you think
I've been dealing with remote system administration?

>Especially since you're using disgustingly awful technology to do it, and
>it doesn't make sense to blame the problems of this technology which you
>_can't_ change (EMP, Phoenix BIOS), on NetBSD which you _can_ change.


>All you end up doing is corrupting and disgustifying NetBSD.  As long as
>the changes you provide are generalizable, don't break working
>installations that are simpler than yours, and don't merely rearrange the
>defaults to match Phoenix EMP Server BIOS Document 454-234A10-x, I'm all
>for including them in the boot blocks.

Mike, please read that FreeBSD URL I re-posted.




>As for LILO, it seems you're right that we don't have a persistent boot
>option storage system.  However, we also don't seem to have any boot
>options that need to be stored persistently yet.  

Ahhhhh, but We have _bootloader_ options that need to be persistent.
We currently compile options into the bootblocks, with no way for
software to recover them again later. So we have _no way_ to preserve
those options on an upgrade which has to change bootblocks -- even if
our install/upgrade tools were magically updated tomorrow to do that,
for other system config.


The ones I know about
>are -s to boot single user, -d to enter the debugger, and, what'sit, -a to
>prompt for a root filesystem?  All of which are fairly interactive.  
>Maybe such a thing could eventually become useful, although I can't
>envision the need at the moment.  However I don't think it's fair to
>compare with LILO--we have other (persistent) ways of handling all the
>things LILO needs append= options for.


But we dont have one-time overrides.  From where I'm coming from,
that's a fair gripe.  Think about those machines locked in remote
wiring closets.

If I need to do an upgrade in person, and want a local console, it's
just not good engineering to **permanently** change the console setup.
(You may try and disagree, but you are clearly wrong).  A one-time
override is better engineering. And we dont *have* any, not for
bootblocks. Not that work in any sane or sensible direction.



> o To quickly test something that would have been an option in Linux:
>    ddb-on-boot
> o To store such changes persistently:
>    kernel config files

Nope.  That leaves out parameters for bootblocks.  It leaves out being
able to *update* bootblocks.



>The NetBSD architecture, as usual, requires you to learn more. 


I have no problem with learning more.  I have a problem with kludges
which don't fit the approved NetBSD way of doing things.  For my purposes,
That's what the bootblock features are.

 but, the
>things you learn are useful.  You're less likely to need to use the
>feature at all in the first place, because NetBSD does not flippantly
>assign kernel options to things that can be done automatically (like
>Linux's console= and root filesystem selection). And the underlying code
>is superior from a developer's perspective, not to mention more
>machine-independent.


Mike, you just agreed with me and disagreed with yourself.  The plain
fact is that NetBSD does NOT automatically select consoles.  The plain
fact is that there ARE no one-time overrides, not for XON/XOFF
braindamage or for switching *from* a serial console *to* a VGA
console.

That's the whole *PROBLEM* here!  Have you listened to anything?


[snip lots]

But DDB is not really an acceptable tool for endusers or for
"production" systems. If you buy that, athen wno, we don't have a
one-time config tool. FreeBSD has had one for years (tho' PCI and PnP
means its less useful than it once was).


>This sort of thinking is even better considering NetBSD's embedded-OS
>future.  Changing a config file and rebuilding is a lot less crufty than
>writing a custom loader to pass information.  There's less custom in-house
>code to provide, fewer subsystems to break, and less client-side state.


But Mike, I am not asking for an embedded OS. I'm asking for robust,
remotely-manageable servers.  As robust as, say, a microvax, or a
server "DECstation", and hopefully better (since the PROM does so much
less, we peforce have more software control).

I thought that's what "serial console" *meant*. Apparently not, in NetBSD.