This is a continuation of a previous discussion. There are
serial interfaces to IPMI chips that I need to support and
I need a way to access these at panic time or when the
system is in a state where it can't schedule.
I have written a layered driver for the serial core, but Alan
says that a
This is a continuation of a previous discussion. There are
serial interfaces to IPMI chips that I need to support and
I need a way to access these at panic time or when the
system is in a state where it can't schedule.
I have written a layered driver for the serial core, but Alan
says that a
Am 11.12.2006 18:07 schrieb Corey Minyard:
> Tilman Schmidt wrote:
>> I was under the impression that line disciplines need a user space
>> process to open the serial device and push them onto it. Is there
>> a way for a driver to attach to a serial port through the line
>> discipline interface
Am 11.12.2006 18:40 schrieb Alan:
> On Mon, 11 Dec 2006 17:58:29 +0100
> Tilman Schmidt <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
>>> This looks wrong. You already have a kernel interface to serial drivers.
>>> It is called a line discipline. We use it for
Am 11.12.2006 18:40 schrieb Alan:
On Mon, 11 Dec 2006 17:58:29 +0100
Tilman Schmidt [EMAIL PROTECTED] wrote:
On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
This looks wrong. You already have a kernel interface to serial drivers.
It is called a line discipline. We use it for ppp, we use it
Am 11.12.2006 18:07 schrieb Corey Minyard:
Tilman Schmidt wrote:
I was under the impression that line disciplines need a user space
process to open the serial device and push them onto it. Is there
a way for a driver to attach to a serial port through the line
discipline interface from kernel
On Mon, 11 Dec 2006, Alan wrote:
> > there as "protocols" for user-tty interfaces, i.e., you need a user, that
> > opens a tty, sets a line discipline to it, and does io (read/write) over
> > it, and NOT to be completely initialised and driven from the kernel.
>
> Take a look at the SLIP
On Mon, 11 Dec 2006, Alan wrote:
> On Sun, 10 Dec 2006 19:23:54 -0600
> Corey Minyard <[EMAIL PROTECTED]> wrote:
>
> > Nothing has come of this yet. But we have these two requests and a
> > request from Russell Doty at Redhat.
> >
> > It would be nice to know if this type of thing was
> there as "protocols" for user-tty interfaces, i.e., you need a user, that
> opens a tty, sets a line discipline to it, and does io (read/write) over
> it, and NOT to be completely initialised and driven from the kernel.
Take a look at the SLIP driver. User space sets up the port but all the
On Mon, 11 Dec 2006 17:58:29 +0100
Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
> > This looks wrong. You already have a kernel interface to serial drivers.
> > It is called a line discipline. We use it for ppp, we use it for slip, we
> > use it for
Alan wrote:
This is going to require some more thought. But I believe it can be
done with adding a poll routine to the tty_operations structure
What status do you need to poll ?
I need to poll for receive and transmit characters so I can do I/O
during panics (interrupts disabled).
> I was actually wrong, flush_to_ldisc does handle reentrancy.
> It can only have one caller to disc->receive_buf() at a time. So
> long chains of recursion don't seem to be possible, even if called
> from IRQ context.
disc->receive_buf is single threaded but if it then sends characters back
in
Tilman Schmidt wrote:
On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
This looks wrong. You already have a kernel interface to serial drivers.
It is called a line discipline. We use it for ppp, we use it for slip, we
use it for a few other things such as attaching sync drivers to some
On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
> This looks wrong. You already have a kernel interface to serial drivers.
> It is called a line discipline. We use it for ppp, we use it for slip, we
> use it for a few other things such as attaching sync drivers to some
> devices.
I was under the
Alan wrote:
On Mon, 11 Dec 2006 08:52:20 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
So here's the start of discussion:
1) The IPMI driver needs to run at panic time to modify watchdog
timers and store panic information in the event log. So no work
queues, no delayed work, and the need
On Mon, 11 Dec 2006 08:52:20 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
> So here's the start of discussion:
>
> 1) The IPMI driver needs to run at panic time to modify watchdog
> timers and store panic information in the event log. So no work
> queues, no delayed work, and the need for some
Alan wrote:
On Sun, 10 Dec 2006 19:23:54 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
Nothing has come of this yet. But we have these two requests and a
request from Russell Doty at Redhat.
It would be nice to know if this type of thing was acceptable or not,
and the problems with the
On Sun, 10 Dec 2006 19:23:54 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:
> Nothing has come of this yet. But we have these two requests and a
> request from Russell Doty at Redhat.
>
> It would be nice to know if this type of thing was acceptable or not,
> and the problems with the patch.
On Sun, 10 Dec 2006 19:23:54 -0600
Corey Minyard [EMAIL PROTECTED] wrote:
Nothing has come of this yet. But we have these two requests and a
request from Russell Doty at Redhat.
It would be nice to know if this type of thing was acceptable or not,
and the problems with the patch. The
Alan wrote:
On Sun, 10 Dec 2006 19:23:54 -0600
Corey Minyard [EMAIL PROTECTED] wrote:
Nothing has come of this yet. But we have these two requests and a
request from Russell Doty at Redhat.
It would be nice to know if this type of thing was acceptable or not,
and the problems with the
On Mon, 11 Dec 2006 08:52:20 -0600
Corey Minyard [EMAIL PROTECTED] wrote:
So here's the start of discussion:
1) The IPMI driver needs to run at panic time to modify watchdog
timers and store panic information in the event log. So no work
queues, no delayed work, and the need for some type
Alan wrote:
On Mon, 11 Dec 2006 08:52:20 -0600
Corey Minyard [EMAIL PROTECTED] wrote:
So here's the start of discussion:
1) The IPMI driver needs to run at panic time to modify watchdog
timers and store panic information in the event log. So no work
queues, no delayed work, and the need
On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
This looks wrong. You already have a kernel interface to serial drivers.
It is called a line discipline. We use it for ppp, we use it for slip, we
use it for a few other things such as attaching sync drivers to some
devices.
I was under the
Tilman Schmidt wrote:
On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
This looks wrong. You already have a kernel interface to serial drivers.
It is called a line discipline. We use it for ppp, we use it for slip, we
use it for a few other things such as attaching sync drivers to some
I was actually wrong, flush_to_ldisc does handle reentrancy.
It can only have one caller to disc-receive_buf() at a time. So
long chains of recursion don't seem to be possible, even if called
from IRQ context.
disc-receive_buf is single threaded but if it then sends characters back
in the
Alan wrote:
This is going to require some more thought. But I believe it can be
done with adding a poll routine to the tty_operations structure
What status do you need to poll ?
I need to poll for receive and transmit characters so I can do I/O
during panics (interrupts disabled).
On Mon, 11 Dec 2006 17:58:29 +0100
Tilman Schmidt [EMAIL PROTECTED] wrote:
On Mon, 11 Dec 2006 10:20:16 +, Alan wrote:
This looks wrong. You already have a kernel interface to serial drivers.
It is called a line discipline. We use it for ppp, we use it for slip, we
use it for a few
there as protocols for user-tty interfaces, i.e., you need a user, that
opens a tty, sets a line discipline to it, and does io (read/write) over
it, and NOT to be completely initialised and driven from the kernel.
Take a look at the SLIP driver. User space sets up the port but all the
actual
On Mon, 11 Dec 2006, Alan wrote:
On Sun, 10 Dec 2006 19:23:54 -0600
Corey Minyard [EMAIL PROTECTED] wrote:
Nothing has come of this yet. But we have these two requests and a
request from Russell Doty at Redhat.
It would be nice to know if this type of thing was acceptable or not,
On Mon, 11 Dec 2006, Alan wrote:
there as protocols for user-tty interfaces, i.e., you need a user, that
opens a tty, sets a line discipline to it, and does io (read/write) over
it, and NOT to be completely initialised and driven from the kernel.
Take a look at the SLIP driver. User
30 matches
Mail list logo
