[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Serial (was: patch for the commands chapter)

From: Christoph Plattner
Subject: Re: Serial (was: patch for the commands chapter)
Date: Sat, 07 Oct 2000 01:20:55 +0200

Hi GRUBers !

I am not happy with this idea behind the thing. I thought the 
"press any key" is only for the first development state, not
for the release.

I have a non-standard oppinion, but for me GRUB is correct
the other way round. Default is serial and a video+keyboard
is a special feature ...... (forget it again)...

First of all, I really want to have the possibility to activate
serial console by a build switch (at ./configure), to have
serial support, even if there is *no* `menu.lst' file. Of 
course this switch should not be the only method, but an
very important one.

If we think about target hardware, definitly no monitor 
or keyboard is plugged on, and there often is none graphics
adapter. In this case I want to have the possibility to
use serial console. Although no user sits on the 'diagnose'
terminal. In our company, for example, we use automated
test suites to test operating system functionality. The
test suite also reboots the machine very often, and it is
not possible (or with additional work only) that GRUB always
wants a user reaction on the serial console to output there
data on booting (which should be logged for test results).

So I think, GRUB should use the mode defined in `menu.lst'.
Or we use the way, as Etherboot does, to have the serial and
the video output in parallel. This is not impossible to
implement. On the reading side the check_key () checks the
keyboard and the serial console simultaneously.

A serial console is 'so basic', so there is no reason, why this
should not work. Also at home I use many PCs only over serial
console. And it is awful for me to attach a graphics card, a
monitor and a keyboard only to do a BIOS setup (because also 
here the serial console and a other setup way should be
the default or at least a feature).

So my suggestion:
        * if the user defines serial, then use serial....
        ... or use the console in parallel
        * add the possibility to define a standard setup for serial
                console per build enviornment, like
                using the default of COM1 (ttyS0).
                This switch should fix switch on serial console +
                configure the baud, etc, to can use it without
                `menu.lst' also as possible default setup.

If you want, I will help....
... but don't treat the seriel console as special feature, often
        is it the standard.

Sorry for that long 'message', but I am a 'serial console fan'
and it is an important point for me, that is also the reason,
why I tried to help the GRUB-community.

With friendly regards

        Christoph Plattner

OKUJI Yoshinori wrote:
> From: Alessandro Rubini <address@hidden>
> Subject: Serial (was: patch for the commands chapter)
> Date: Fri, 6 Oct 2000 11:35:15 +0200
> > But the user may not run a local console when the "terminal" command
> > is executed from the configuration file.
>   You are completely misunderstanding that. When the user runs
> "terminal serial", the user must press a key from a _remote_ host.
> > And if the user is
> > interactive and requests "terminal serial" without having a serial
> > connection it's user's fault.
>   This is also a policy, isn't this?
> > Hmm... or is the "press any key" displayed to the serial console?
>   Of course.
> > so, things are less bad than they could be, but still bad. Why should
> > it stop there (and by default it stops for an infinite time) before
> > going on with its tasks?
>   I have already told you the reason.
> > Does the "halt" or "reboot" command ask to enter any key? Obviously
> > not.
>   Why do you want to compare it with "halt" or "reboot"?
> > >From my reading of the code, at timeout expiration GRUB resets the
> > default terminal. So setting the timeout to 0 means "no serial console".
>   That's wrong. I'm tired from explaining the internals. Try to use
> it. It is a bad thing to conclude something without any actual test.
> > BTW: the exchange of "speed" and "port" is from 2000/09/01, the
> > original bug was having two "port" and no "speed", but the fix was
> > incorrect (from cvs diff).
>   You are right. That's my mistake.
> Okuji
> _______________________________________________
> Bug-grub mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-grub

private:        address@hidden
company:        address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]