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 archi
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
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, <[EMAI
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,
* 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]>
-
To unsubscribe from t
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 paper
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 bu
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
> >
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
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
> 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
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 TF
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. Ei
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 cou
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
Tim Wright wrote:
>
> Yup,
> those who fail to learn from TCP are doomed to re-invent it, badly, at the
> wrong level .
> 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
Yup,
those who fail to learn from TCP are doomed to re-invent it, badly, at the
wrong level .
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
> 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-k
> 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
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 (whic
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 t
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.
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 m
> 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 bas
> 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
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
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
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 inc
> > 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
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. V
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
> alrea
> 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
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 pl
> 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 mak
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
> > 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 wors
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 U
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,
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 character
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 (
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
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
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
43 matches
Mail list logo
