Hello,
I'd like to have a LILO version that supports higher serial speeds than
9600bps. Questions:
- Is there a version that already does that?
- If not, do I need to change just LILO to do that, or do I need to change
the kernel as well (I don't think I'd need to do that too, as the serial
console kernel code does support up to 115.2Kbps, but it doesn't hurt to
ask ... ;) ??
- Does another bootloader (e.g. GRUB) support serial speeds higher than
9600bps?? If so, which one(s)??
TIA for your help!!
Later,
Ivan
On Mon, 12 Feb 2001, Ivan Passos wrote:
>
> I'd like to have a LILO version that supports higher serial speeds than
> 9600bps. Questions:
> - Is there a version that already does that?
To answer one of my own questions: my current LILO version does support
speeds up to 38400bps. I didn't try it before because the _man page_ said
it supported up to 9600 (and I believed in it :), but after checking
LILO's Changelog, I found that support for speeds up to 38400 is available
for a long time now. I tested it running at 38400 and it works.
Since I still want to add support for speeds up to 115200, the other two
questions are still up (see below):
> - If not, do I need to change just LILO to do that, or do I need to change
> the kernel as well (I don't think I'd need to do that too, as the serial
> console kernel code does support up to 115.2Kbps, but it doesn't hurt to
> ask ... ;) ??
> - Does another bootloader (e.g. GRUB) support serial speeds higher than
> 9600bps?? If so, which one(s)??
I'd really appreciate any help.
Later,
Ivan
Followup to: <[email protected]>
By author: Ivan Passos <[email protected]>
In newsgroup: linux.dev.kernel
>
> Since I still want to add support for speeds up to 115200, the other two
> questions are still up (see below):
>
> > - If not, do I need to change just LILO to do that, or do I need to change
> > the kernel as well (I don't think I'd need to do that too, as the serial
> > console kernel code does support up to 115.2Kbps, but it doesn't hurt to
> > ask ... ;) ??
> > - Does another bootloader (e.g. GRUB) support serial speeds higher than
> > 9600bps?? If so, which one(s)??
>
> I'd really appreciate any help.
>
SYSLINUX supports up to 57600 (it doesn't support 115200 because it
stores the number in a 16-bit register) but seriously... why the heck
does this matter? It isn't booting the kernel off the serial line,
you know. A console at 38400 is really quite sufficient... if you
need something more than that, you probably should be logging in via
the network.
I have toyed a few times about having a simple Ethernet- or UDP-based
console protocol (TCP is too heavyweight, sorry) where a machine would
seek out a console server on the network. Anyone has any ideas about
it?
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Followup to: <[email protected]>
By author: Ivan Passos <[email protected]>
In newsgroup: linux.dev.kernel
>
> Since I still want to add support for speeds up to 115200, the other two
> questions are still up (see below):
>
Just checked my own code, and SYSLINUX does indeed support 115200 (I
changed this to be a 32-bit register ages ago, apparently.) Still
doesn't answer the question "why"... all I think you do is increase
the risk for FIFO overrun and lost characters (flow control on a boot
loader console is vestigial at the best.)
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On 12 Feb 2001, H. Peter Anvin wrote:
>
> Just checked my own code, and SYSLINUX does indeed support 115200 (I
> changed this to be a 32-bit register ages ago, apparently.) Still
> doesn't answer the question "why"... all I think you do is increase
> the risk for FIFO overrun and lost characters (flow control on a boot
> loader console is vestigial at the best.)
It's simple -- we want the kernel to have its serial console running at
115200, and we don't want to have to change speeds to talk to the
bootloader. Some boot processes, particularaly fsck, can be *REALLY*
verbose on screwed up systems. I've seen systems take hours to run fsck,
even on small filesystems, simply because they were blocking on a 9600 bps
console.
Scott
On 12 Feb 2001, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Ivan Passos <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Since I still want to add support for speeds up to 115200, the other two
> > questions are still up (see below):
> >
> > > - If not, do I need to change just LILO to do that, or do I need to change
> > > the kernel as well (I don't think I'd need to do that too, as the serial
> > > console kernel code does support up to 115.2Kbps, but it doesn't hurt to
> > > ask ... ;) ??
> > > - Does another bootloader (e.g. GRUB) support serial speeds higher than
> > > 9600bps?? If so, which one(s)??
> >
> > I'd really appreciate any help.
> >
>
> SYSLINUX supports up to 57600 (it doesn't support 115200 because it
> stores the number in a 16-bit register) but seriously... why the heck
> does this matter? It isn't booting the kernel off the serial line,
> you know. A console at 38400 is really quite sufficient... if you
> need something more than that, you probably should be logging in via
> the network.
>
> I have toyed a few times about having a simple Ethernet- or UDP-based
> console protocol (TCP is too heavyweight, sorry) where a machine would
> seek out a console server on the network. Anyone has any ideas about
> it?
Excellent plan: data centre sysadmins the world over will worship your
name if it works...
What exactly do you have in mind: a bidirectional connection you could
use to control everything from LILO/Grub onwards? Should be feasible,
anyway.
I'd go with UDP for this, rather than raw Ethernet. Use DHCP to get the IP
address(es) to connect to as console hosts? (That or a command line
option...)
The first thing is the kernel: just wrap around printk so as soon as eth0
is up, you set up a session and start sending packets.
I'll do a server to receive these sessions - simple text (no vt100 etc),
one window per session - and work on the protocol spec. Anyone willing
to do the client end of things - lilo, grub, kernel, etc??
James.
James Sutherland wrote:
>
> Excellent plan: data centre sysadmins the world over will worship your
> name if it works...
>
> What exactly do you have in mind: a bidirectional connection you could
> use to control everything from LILO/Grub onwards? Should be feasible,
> anyway.
>
> I'd go with UDP for this, rather than raw Ethernet. Use DHCP to get the IP
> address(es) to connect to as console hosts? (That or a command line
> option...)
>
Yes, that's my thinking too. A DHCP/BOOTP option seems to be the obvious
way, and I'd hate to use non-obvious ways when there is a perfectly good
obvious way.
> The first thing is the kernel: just wrap around printk so as soon as eth0
> is up, you set up a session and start sending packets.
My thinking at the moment is to require kernel IP configuration (either
ip= or RARP/BOOTP/DHCP). It seems to be the only practical way;
otherwise you miss too much at the beginning. However, that mechanism is
already in place, and shouldn't be too hard to piggy-back on.
> I'll do a server to receive these sessions - simple text (no vt100 etc),
> one window per session - and work on the protocol spec. Anyone willing
> to do the client end of things - lilo, grub, kernel, etc??
I'll do PXELINUX, for sure. I'd prefer to do the protocol spec, if you
don't mind -- having done PXELINUX I think I know the kinds of pitfalls
that you run into doing an implementation in firmware or firmware-like
programming (PXELINUX isn't firmware, but it might as well be.)
Doing it in LILO would be extremely difficult, since LILO has no ability
to handle networking, and no reasonable way to graft it on (you need a
driver for networking.) GRUB I can't really comment on.
I might just decide to do the kernel as well.
Hmmm... this sounds like it's turning into a group effort. Would you (or
someone else) like to set up a sourceforge project for this? I would
prefer not to have to deal with that end myself.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> > I have toyed a few times about having a simple Ethernet- or UDP-based
> > console protocol (TCP is too heavyweight, sorry) where a machine would
> > seek out a console server on the network. Anyone has any ideas about
> > it?
>
> Excellent plan: data centre sysadmins the world over will worship your
> name if it works...
Sounds like MOP on the old Vaxen. TCP btw isnt as heavyweight as people
sometimes think. You can (and people have) implemented a simple TCP client
and IP and SLIP in 8K of EPROM on a 6502. There is a common misconception
that a TCP must be complex.
All you actually _have_ to support is receiving frames in order, sending one
frame at a time when the last data is acked and basic backoff. You dont have
to parse tcp options, you dont have to support out of order reassembly.
Alan Cox wrote:
>
> Sounds like MOP on the old Vaxen. TCP btw isnt as heavyweight as people
> sometimes think. You can (and people have) implemented a simple TCP client
> and IP and SLIP in 8K of EPROM on a 6502. There is a common misconception
> that a TCP must be complex.
>
> All you actually _have_ to support is receiving frames in order, sending one
> frame at a time when the last data is acked and basic backoff. You dont have
> to parse tcp options, you dont have to support out of order reassembly.
>
This is true, but one thing I'd really like to have is controlled buffer
overrun, which TCP *doesn't* have. I really think an ad hoc UDP protocol
(I've already begun sketching on the details) is more appropriate in this
particular case.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> This is true, but one thing I'd really like to have is controlled buffer
> overrun, which TCP *doesn't* have. I really think an ad hoc UDP protocol
> (I've already begun sketching on the details) is more appropriate in this
> particular case.
Explain 'controlled buffer overrun'. BTW if you make it UDP please include
something like SHA hash or tea hash and shared secret
On Mon, 12 Feb 2001, Alan Cox wrote:
> > > I have toyed a few times about having a simple Ethernet- or UDP-based
> > > console protocol (TCP is too heavyweight, sorry) where a machine would
> > > seek out a console server on the network. Anyone has any ideas about
> > > it?
> >
> > Excellent plan: data centre sysadmins the world over will worship your
> > name if it works...
>
> Sounds like MOP on the old Vaxen. TCP btw isnt as heavyweight as people
> sometimes think. You can (and people have) implemented a simple TCP client
> and IP and SLIP in 8K of EPROM on a 6502. There is a common misconception
> that a TCP must be complex.
>
> All you actually _have_ to support is receiving frames in order, sending one
> frame at a time when the last data is acked and basic backoff. You dont have
> to parse tcp options, you dont have to support out of order reassembly.
It's not a huge undertaking, I know, but UDP will probably still be
a bit simpler. Turn the question around: would using TCP bring any real
benefits, in a system which will only be used to shift a few kb each boot
time?
At a later date, perhaps TCP could be used - it would certainly make sense
for the kernel-side code: once you have a fully-fledged IP stack, why not
use it. There's no reason the server couldn't support both, and machines
would just use whichever was more appropriate at the time.
James.
> It's not a huge undertaking, I know, but UDP will probably still be
> a bit simpler. Turn the question around: would using TCP bring any real
> benefits, in a system which will only be used to shift a few kb each boot
> time?
Im not convinced it will be any smaller by the time your UDP code has dealt
with retransmits, out of order acks, and backoff.
> for the kernel-side code: once you have a fully-fledged IP stack, why not
> use it. There's no reason the server couldn't support both, and machines
> would just use whichever was more appropriate at the time.
The IP layer is easy. Thats about 30 lines of code for a minimal IP. You'll
need more code to implement ARP, which you will require
On Mon, 12 Feb 2001, H. Peter Anvin wrote:
> James Sutherland wrote:
> >
> My thinking at the moment is to require kernel IP configuration (either
> ip= or RARP/BOOTP/DHCP). It seems to be the only practical way;
> otherwise you miss too much at the beginning. However, that mechanism is
> already in place, and shouldn't be too hard to piggy-back on.
Yes: that should be easy enough, specially DHCP and ip=.
> > I'll do a server to receive these sessions - simple text (no vt100 etc),
> > one window per session - and work on the protocol spec. Anyone willing
> > to do the client end of things - lilo, grub, kernel, etc??
>
> I'll do PXELINUX, for sure. I'd prefer to do the protocol spec, if you
> don't mind -- having done PXELINUX I think I know the kinds of pitfalls
> that you run into doing an implementation in firmware or firmware-like
> programming (PXELINUX isn't firmware, but it might as well be.)
Fine by me: we seem to agree on the basic concept already, and there isn't
going to be very much protocol involved!
> Doing it in LILO would be extremely difficult, since LILO has no ability
> to handle networking, and no reasonable way to graft it on (you need a
> driver for networking.) GRUB I can't really comment on.
I haven't seen much of GRUB, but it does seem to have DHCP support, so it
must have some facility for sending/receiving packets. LILO's command-line
approach would be better suited to this, really, though...
> I might just decide to do the kernel as well.
>
> Hmmm... this sounds like it's turning into a group effort. Would you (or
> someone else) like to set up a sourceforge project for this? I would
> prefer not to have to deal with that end myself.
OK, I've filled in the paperwork - we should have a project account
sometime tomorrow. I put the license type as "Other", since the heart of
the project is the protocol, and patches to add support to the kernel,
FreeBSD etc. will have to be under the license of the OS in question.
Title: "Network Console Protocol" for now?
James.
Alan Cox wrote:
> Explain 'controlled buffer overrun'.
That's probably the ability to send new data even if there's unacked old
data (e.g. because the receiver can't keep up or because we've had losses).
Such a feature would be mainly useful in cases where data becomes useless
if too old, e.g. VoIP. Ironically, for the console, the opposite may be
true: if the kernel all of a sudden starts vomiting printks, the relevant
information is more likely to be at the beginning than at the end.
One advantage of TCP would be that such an implementation is more likely
to get congestion control right, so it would be safer to use over the
Internet. (And using UDP wouldn't make this any easier.) Also, when using
TCP, it's more likely that some reasonable session management is built
into the design.
BTW, as far as the boot loader is concerned: any of the Linux boots Linux
designs should nicely solve this, with the possible exception of
environments where a legacy OS needs to be booted. Reminds me that I should
find some time besides traffic control to work a bit on bootimg ...
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
On Mon, 12 Feb 2001, Scott Laird wrote:
>
> On 12 Feb 2001, H. Peter Anvin wrote:
> >
> > Just checked my own code, and SYSLINUX does indeed support 115200 (I
> > changed this to be a 32-bit register ages ago, apparently.) Still
> > doesn't answer the question "why"... all I think you do is increase
> > the risk for FIFO overrun and lost characters (flow control on a boot
> > loader console is vestigial at the best.)
>
> It's simple -- we want the kernel to have its serial console running at
> 115200, and we don't want to have to change speeds to talk to the
> bootloader.
Exactly.
Then HPA may ask: but why do you want to run the serial console at
115200?? The answer is simple: because we can (or more precisely, because
the HW can ;).
If the hardware is supposed to support 115.2Kbps, why can't / shouldn't
we use it?? Remember, this is not a modem connection, there is no
compression involved, both sides are running 115.2Kbps, so there should
NOT be a risk for FIFO overruns (unless you have buggy hardware). And in
this case, you can then decrease your baud rate. But at least you have the
_option_! :)
> Some boot processes, particularaly fsck, can be *REALLY*
> verbose on screwed up systems. I've seen systems take hours to run fsck,
> even on small filesystems, simply because they were blocking on a 9600 bps
> console.
This is true!!
Another one (not as critical as the fsck though): when compiling the
kernel, sometimes the kernel compilation is done, but the console output
isn't finished yet (I'm serious).
Later,
Ivan
> > Explain 'controlled buffer overrun'.
>
> That's probably the ability to send new data even if there's unacked old
> data (e.g. because the receiver can't keep up or because we've had losses).
Well let me see, the typical window on the other end of the connection if
its a normal PC class host will be 32K. I think that should be sufficient.
Alan Cox wrote:
>
> > > Explain 'controlled buffer overrun'.
> >
> > That's probably the ability to send new data even if there's unacked old
> > data (e.g. because the receiver can't keep up or because we've had losses).
>
> Well let me see, the typical window on the other end of the connection if
> its a normal PC class host will be 32K. I think that should be sufficient.
>
Depends on what the client can handle. For the kernel, that might be
true, but for example a boot loader may only have a few K worth of buffer
space.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Alan Cox wrote:
>
> > This is true, but one thing I'd really like to have is controlled buffer
> > overrun, which TCP *doesn't* have. I really think an ad hoc UDP protocol
> > (I've already begun sketching on the details) is more appropriate in this
> > particular case.
>
> Explain 'controlled buffer overrun'. BTW if you make it UDP please include
> something like SHA hash or tea hash and shared secret
>
I *REALLY* don't know if that is reasonable; it may have to fall into the
category of "supported but not required". Requiring an SHA hash in a
small bootstrap loader may not exactly be a reasonable expectation!
However, I think the protocol is inherently going to be asymmetric, with
as much as possible unloaded.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> I *REALLY* don't know if that is reasonable; it may have to fall into the
> category of "supported but not required". Requiring an SHA hash in a
> small bootstrap loader may not exactly be a reasonable expectation!
tea is very very small so may be appropriate instead.
> However, I think the protocol is inherently going to be asymmetric, with
> as much as possible unloaded.
Nod.
> Depends on what the client can handle. For the kernel, that might be
> true, but for example a boot loader may only have a few K worth of buffer
> space.
That same constraint is true of any UDP protocol too, and indeed any protocol
not entirely based on FEC (which rather rules out ethernet based solutions)
You also dont need much buffering for a smart embedded stack, its no secret
that some embedded tcps dont buffer the data but pointers to constant data and
values for only non constant objects. You really can make a minimal TCP very
low resource.
Alan
On Mon, Feb 12, 2001 at 03:17:04PM -0800, Ivan Passos wrote:
Then HPA may ask: but why do you want to run the serial console
at 115200?? The answer is simple: because we can (or more
precisely, because the HW can ;).
Actually... consider debugging PCI hardware on a large SMP box; you
get lots of kernel messages and even reboot is slowed by the volume
you see there.
There you want as fast a console as you can possibly have...
--cw
On Mon, 12 Feb 2001, H. Peter Anvin wrote:
> Alan Cox wrote:
> >
> > > > Explain 'controlled buffer overrun'.
> > >
> > > That's probably the ability to send new data even if there's unacked old
> > > data (e.g. because the receiver can't keep up or because we've had losses).
> >
> > Well let me see, the typical window on the other end of the connection if
> > its a normal PC class host will be 32K. I think that should be sufficient.
>
> Depends on what the client can handle. For the kernel, that might be
> true, but for example a boot loader may only have a few K worth of buffer
> space.
Fortunately, the bulky stuff (printk's from the booting kernel) will be
going from the boot loader to the server, and should be buffered there
OK until they can be processed. Only the stuff sent to the client will
need buffering, and that should be simple keystrokes...
James.
On Mon, Feb 12, 2001 at 03:17:04PM -0800, Ivan Passos wrote:
>
> On Mon, 12 Feb 2001, Scott Laird wrote:
> >
> > On 12 Feb 2001, H. Peter Anvin wrote:
> > >
> > > Just checked my own code, and SYSLINUX does indeed support 115200 (I
> > > changed this to be a 32-bit register ages ago, apparently.) Still
> > > doesn't answer the question "why"... all I think you do is increase
> > > the risk for FIFO overrun and lost characters (flow control on a boot
> > > loader console is vestigial at the best.)
> >
> > It's simple -- we want the kernel to have its serial console running at
> > 115200, and we don't want to have to change speeds to talk to the
> > bootloader.
>
> Exactly.
>
> Then HPA may ask: but why do you want to run the serial console at
> 115200?? The answer is simple: because we can (or more precisely, because
> the HW can ;).
>
> If the hardware is supposed to support 115.2Kbps, why can't / shouldn't
> we use it?? Remember, this is not a modem connection, there is no
> compression involved, both sides are running 115.2Kbps, so there should
> NOT be a risk for FIFO overruns (unless you have buggy hardware). And in
> this case, you can then decrease your baud rate. But at least you have the
> _option_! :)
>
>
> > Some boot processes, particularaly fsck, can be *REALLY*
> > verbose on screwed up systems. I've seen systems take hours to run fsck,
> > even on small filesystems, simply because they were blocking on a 9600 bps
> > console.
>
> This is true!!
>
> Another one (not as critical as the fsck though): when compiling the
> kernel, sometimes the kernel compilation is done, but the console output
> isn't finished yet (I'm serious).
Dunno about others, but I always pipe stdout to /dev/null when compiling
kernels. This way, everything important is still shown (warnings/errors)
as those go to stderr anyway, and all non-interesting stuff goes down
the drain.
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
James Sutherland wrote:
> >
> > Depends on what the client can handle. For the kernel, that might be
> > true, but for example a boot loader may only have a few K worth of buffer
> > space.
>
> Fortunately, the bulky stuff (printk's from the booting kernel) will be
> going from the boot loader to the server, and should be buffered there
> OK until they can be processed. Only the stuff sent to the client will
> need buffering, and that should be simple keystrokes...
>
Well, any time there is a network there needs to be buffering, if you
want to have any kind of ACK protocol.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Alan Cox wrote:
>
> > Depends on what the client can handle. For the kernel, that might be
> > true, but for example a boot loader may only have a few K worth of buffer
> > space.
>
> That same constraint is true of any UDP protocol too, and indeed any protocol
> not entirely based on FEC (which rather rules out ethernet based solutions)
>
> You also dont need much buffering for a smart embedded stack, its no secret
> that some embedded tcps dont buffer the data but pointers to constant data and
> values for only non constant objects. You really can make a minimal TCP very
> low resource.
>
I'm sure you can. That doesn't mean it's the right solution.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> Then HPA may ask: but why do you want to run the serial console at
> 115200?? The answer is simple: because we ...
... don't want to drag out debugging the kernel on a 38400 connection.
Because printks are our only debugging option ("thanks", Linus), and a slow
serial port block and can change the timing of when code runs, I need the
serial port to run as fast as possible. It would be keen to be able to use
an ethernet debugging console rather than (or in addition to) serial,
because it would be even faster, and if I'm debugging (for instance) a
serial driver, I won't have to use the system I'm debugging to debug the
system I'm debugging.
Of course, a supported kernel debugger would make a nice addition to faster
console output, but I won't hold my breath waiting for Linux to acquire what
pretty much every other operating system already has.
-M
> I'm sure you can. That doesn't mean it's the right solution.
And the UDP proposal will be at least as big if it does retransmits, and if
it doesnt , its junk. It will also need as much buffering, if not the same
packing trick
Yup,
those who fail to learn from TCP are doomed to re-invent it, badly, at the
wrong level <GRIN>.
Seriously, the console subsystem on the Sequent (now IBM) NUMA-Q systems
originally used UDP. It wound up as a serious mess. We changed to TCP.
I'll admit that the NUMA-Q console subsystem does more than what is being
proposed here currently, but it's likely to grow.
In general UDP is only appropriate if you *can* afford to drop data.
Did RDP ever get anywhere ?
Regards,
Tim
On Tue, Feb 13, 2001 at 12:11:01AM +0000, Alan Cox wrote:
> > I'm sure you can. That doesn't mean it's the right solution.
>
> And the UDP proposal will be at least as big if it does retransmits, and if
> it doesnt , its junk. It will also need as much buffering, if not the same
> packing trick
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://vger.kernel.org/lkml/
--
Tim Wright - [email protected] or [email protected] or [email protected]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
Tim Wright wrote:
>
> Yup,
> those who fail to learn from TCP are doomed to re-invent it, badly, at the
> wrong level <GRIN>.
> Seriously, the console subsystem on the Sequent (now IBM) NUMA-Q systems
> originally used UDP. It wound up as a serious mess. We changed to TCP.
> I'll admit that the NUMA-Q console subsystem does more than what is being
> proposed here currently, but it's likely to grow.
> In general UDP is only appropriate if you *can* afford to drop data.
> Did RDP ever get anywhere ?
>
That's the whole crux of the matter. For something like this, you *will*
drop data under certain circumstances. I suspect it's better to have
this done in a controlled manner, rather than stop completely, which is
what TCP would do.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Mon, 12 Feb 2001, H. Peter Anvin wrote:
> James Sutherland wrote:
> > >
> > > Depends on what the client can handle. For the kernel, that might be
> > > true, but for example a boot loader may only have a few K worth of buffer
> > > space.
> >
> > Fortunately, the bulky stuff (printk's from the booting kernel) will be
> > going from the boot loader to the server, and should be buffered there
> > OK until they can be processed. Only the stuff sent to the client will
> > need buffering, and that should be simple keystrokes...
>
> Well, any time there is a network there needs to be buffering, if you
> want to have any kind of ACK protocol.
Yes, but only the last packet sent, if you limit to one packet at a
time... Shouldn't be a problem, even for the smallest code.
James.
Alan Cox wrote:
>
> > I'm sure you can. That doesn't mean it's the right solution.
>
> And the UDP proposal will be at least as big if it does retransmits, and if
> it doesnt , its junk. It will also need as much buffering, if not the same
> packing trick
>
Within limits, you're right, of course. I suspect it won't be *as* big
(especially not if it's talking to a PXE card which does the IP and UDP
layers in firmware, but not TCP), but I still suspect better tradeoffs
can be made this way.
That being said, I'll look at TCP as well.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
James Sutherland wrote:
> >
> > Well, any time there is a network there needs to be buffering, if you
> > want to have any kind of ACK protocol.
>
> Yes, but only the last packet sent, if you limit to one packet at a
> time... Shouldn't be a problem, even for the smallest code.
>
Of course. Either way I was planning to use the TCP technique of ACKing
a byte position, not a packet number (unlike TFTP.)
Anyway, perhaps we should take this off linux-kernel and reconvene once
we get a sourceforge list up.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
Adrian Levi wrote:
>
> I usually lurk on the list and don't contribute but I would like to
> place my 2 bob in to the fro. Would a modified X-Modem protocol stack suit
> this operation? No sliding window and don't send anything until you
> receive an ack back?
>
Not particularly. Xmodem and TFTP are very similar.
Anyway, I repeat what I said about there being too many cooks in the
kitchen at the moment...
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
> That's the whole crux of the matter. For something like this, you *will*
> drop data under certain circumstances. I suspect it's better to have
> this done in a controlled manner, rather than stop completely, which is
> what TCP would do.
Why do you plan to drop data ? That seems unneccessary.
On Tue, 13 Feb 2001, Alan Cox wrote:
> > That's the whole crux of the matter. For something like this, you *will*
> > drop data under certain circumstances. I suspect it's better to have
> > this done in a controlled manner, rather than stop completely, which is
> > what TCP would do.
>
> Why do you plan to drop data ? That seems unneccessary.
If the kernel starts spewing data faster than you can send it to the far
end, either the data gets dropped, or you block the kernel. Having the
kernel hang waiting to send a printk to the far end seems like a bad
situation...
James.
James Sutherland writes:
> If the kernel starts spewing data faster than you can send it to the far
> end, either the data gets dropped, or you block the kernel. Having the
> kernel hang waiting to send a printk to the far end seems like a bad
> situation...
It can actually be useful. Why? Lets take a real life example: the
recent IDE multi-sector write bug.
In that specific case, I was logging through one 115200 baud serial port
the swapin activity (in do_swap_page), the swap out activity (in
try_to_swap_out), as well as every IDE request down to individual buffers
as they were written to/read from the drive. This produces a rather a
lot of data, far faster than a 115200 baud serial port can send it.
The ability then to run scripts which can interpret the data and
pick out errors (eg, we swap in data that is different from the data
that was swapped out) was invaluable for tracking down the problem.
Had messages been dropped, this would not have been possible or would
have indicated false errors. Blocking the kernel while debug stuff
was sent was far more preferable to loosing messages in this case.
I would imagine that that is also true for the majority of cases as
well.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Tue, 13 Feb 2001, Russell King wrote:
> James Sutherland writes:
> > If the kernel starts spewing data faster than you can send it to the far
> > end, either the data gets dropped, or you block the kernel. Having the
> > kernel hang waiting to send a printk to the far end seems like a bad
> > situation...
>
> It can actually be useful. Why? Lets take a real life example: the
> recent IDE multi-sector write bug.
>
> In that specific case, I was logging through one 115200 baud serial port
> the swapin activity (in do_swap_page), the swap out activity (in
> try_to_swap_out), as well as every IDE request down to individual buffers
> as they were written to/read from the drive. This produces a rather a
> lot of data, far faster than a 115200 baud serial port can send it.
>
> The ability then to run scripts which can interpret the data and
> pick out errors (eg, we swap in data that is different from the data
> that was swapped out) was invaluable for tracking down the problem.
>
> Had messages been dropped, this would not have been possible or would
> have indicated false errors. Blocking the kernel while debug stuff
> was sent was far more preferable to loosing messages in this case.
> I would imagine that that is also true for the majority of cases as
> well.
OK, in this particular case you need to log EVERYTHING for diagnostic
purposes. In most cases, though, I'd rather have some messages dropped
than have the machine slow to a crawl...
Would you be OK with a "blocking netconsole" option, to provide this
behavious where needed? If it's the default, I bet the next Mindcraft
tests will be run with verbose logging on a 9600bps link :-)
Most people wouldn't need/want this, but I can see it would be
useful: giving the user this choice seems a better option. Also, losses on
a 10 or 100 Mbit/sec Ethernet connection will be rather less likely than
they could on a serial link!
James.
Hi!
> > > This is true, but one thing I'd really like to have is controlled buffer
> > > overrun, which TCP *doesn't* have. I really think an ad hoc UDP protocol
> > > (I've already begun sketching on the details) is more appropriate in this
> > > particular case.
> >
> > Explain 'controlled buffer overrun'. BTW if you make it UDP please include
> > something like SHA hash or tea hash and shared secret
> >
>
> I *REALLY* don't know if that is reasonable; it may have to fall into the
> category of "supported but not required". Requiring an SHA hash in a
> small bootstrap loader may not exactly be a reasonable expectation!
> However, I think the protocol is inherently going to be asymmetric, with
> as much as possible unloaded.
Being able to remotely resed machine with crashed userland would be
*very* nice, too...
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
* Pavel Machek ([email protected]) [010217 05:40]:
> Being able to remotely resed machine with crashed userland would be
> *very* nice, too...
If it provides a true remote console, enable SYSRQ and youi should get this
for free.
--
Patrick Michael Kane
<[email protected]>
On Sat, 17 Feb 2001, Patrick Michael Kane wrote:
> * Pavel Machek ([email protected]) [010217 05:40]:
> > Being able to remotely resed machine with crashed userland would be
> > *very* nice, too...
>
> If it provides a true remote console, enable SYSRQ and youi should get this
> for free.
Yes, it should work fine. Of course, there's always the risk you'll
connect to the crashed box from your machine, then hit Alt+SysRq+B, and
say rude things as YOUR machine reboots... :-)
James.
Hi!
> > I might just decide to do the kernel as well.
> >
> > Hmmm... this sounds like it's turning into a group effort. Would you (or
> > someone else) like to set up a sourceforge project for this? I would
> > prefer not to have to deal with that end myself.
>
> OK, I've filled in the paperwork - we should have a project account
> sometime tomorrow. I put the license type as "Other", since the heart of
> the project is the protocol, and patches to add support to the kernel,
> FreeBSD etc. will have to be under the license of the OS in question.
>
> Title: "Network Console Protocol" for now?
Hey, be sure to add magic keys over network console protocol (-:. I
(and mj) long time ago wanted to do magic keys over network, and it
should be pretty easy to add onto network console...
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Hi everyone,
We have set up a network console project on sourceforge and are starting
to work on actual details. If you're interested in this subject please
do join that list.
Please see:
http://sourceforge.net/mail/?group_id=20426
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
On Tue, Feb 20, 2001 at 07:11:26PM -0800, H. Peter Anvin wrote:
> Hi everyone,
>
> We have set up a network console project on sourceforge and are starting
> to work on actual details. If you're interested in this subject please
> do join that list.
DEC's old protocol called MOP (Maintainence and Operations Protocol)
comes in mind...
MfG, JBG
--
Fehler eingestehen, Gr??e zeigen: Nehmt die Rechtschreibreform zur?ck!!!
/* Jan-Benedict Glaw <[email protected]> -- +49-177-5601720 */
keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB
"insmod vi.o and there we go..." (Alexander Viro on linux-kernel)
Hi!
> We have set up a network console project on sourceforge and are starting
> to work on actual details. If you're interested in this subject please
> do join that list.
>
> Please see:
>
> http://sourceforge.net/mail/?group_id=20426
Unfortunately maillist archives at sourceforge do not work.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
You write:
> > We have set up a network console project on sourceforge and are starting
> > to work on actual details. If you're interested in this subject please
> > do join that list.
> >
> > Please see:
> >
> > http://sourceforge.net/mail/?group_id=20426
>
> Unfortunately maillist archives at sourceforge do not work.
Yes, I noticed this as well - there are several bug reports open already.
I have subscribed some of the mailing lists at sourceforge that I'm using
to marc.theaimsgroup.com, which has good searching facilities, etc.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert