Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I guess this is taken care of entirely by my implementation, that just
> closes the ioport:
Sort of. That will cause the underlying port to drop DTR, but only if
you were the only one who had the underlying port open.
_
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Just two issues: What about CSTOP and/or CSIZE, do I handle
> it the way it is done for Mach devices?
I'll say this only one more time.
NO NO NO. You don't handle it the way it is done for Mach devices.
Odds are for *any* question of this form
On Sat, Feb 02, 2002 at 07:42:23PM -0500, Roland McGrath wrote:
> > And do I update the termstate to match reality, eg do I go back and do a
> > tiocgeta and (re)set the speeds?
>
> Yes, I think you should do that. Particular hardware or particular drivers
> will support a certain subset of poss
> I am still unsure (sorry) about one thing. We reset the speed, but what
> about the flags c_cflag. If we just pass them down, and they are not
> honored, what do we do? For example, the character size mask. In
> particular, for those bits in the flag in general, should or should we not
> res
On Sat, Feb 02, 2002 at 07:53:12PM -0500, Roland McGrath wrote:
> > /* Mach forces us to use the normal stop bit convention:
> > two bits at 110 bps; 1 bit otherwise. */
>
> Ah, that stuff is just coping with the crappiness of the Mach device code.
> You can just pass down the CSTO
> On Sat, Feb 02, 2002 at 07:42:23PM -0500, Roland McGrath wrote:
> > > Just two issues: What about CSTOP and/or CSIZE, do I handle it the way it
> > > is done for Mach devices?
> >
> > I don't understand the question. These are serial hardware settings that
> > should be passed down directly ju
On Sat, Feb 02, 2002 at 07:42:23PM -0500, Roland McGrath wrote:
> > Just two issues: What about CSTOP and/or CSIZE, do I handle it the way it
> > is done for Mach devices?
>
> I don't understand the question. These are serial hardware settings that
> should be passed down directly just like the
> Well, ok, I did that (of course, tioctl_tiocgeta takes the arguments a bit
> differently, but that's easy), although I don't know why you set raw mode
> explicitely.
Because you don't want the underlying tty to do ICANON processing and so forth.
> Just two issues: What about CSTOP and/or CSIZE
On Wed, Dec 19, 2001 at 06:35:34PM -0500, Roland McGrath wrote:
> For set_bits, I think you can do:
>
> tioctl_tiocgeta (underlying, &ttystat);
> if (termstate.__ispeed)
> ttystat.__ispeed = termstate.__ispeed;
> if (termstate.__ospeed)
> ttystat.__ospeed = terms
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Thu, Jan 31, 2002 at 03:00:37PM -0800, Thomas Bushnell, BSG wrote:
> > > I can make such requests, but how do I find out that the carrier really has
> > > been established? (Also, it would not allow servers to implement the open
> > > behaviour b
On Thu, Jan 31, 2002 at 03:00:37PM -0800, Thomas Bushnell, BSG wrote:
> > I can make such requests, but how do I find out that the carrier really has
> > been established? (Also, it would not allow servers to implement the open
> > behaviour but not the tiocl bit mangling).
>
> Yeah, you are cor
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I can make such requests, but how do I find out that the carrier really has
> been established? (Also, it would not allow servers to implement the open
> behaviour but not the tiocl bit mangling).
Yeah, you are correct here. You could assert DTR w
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Ok. Now, you avoided to answer what is the better approximation in case
> the underlying file supports tiocoutq. npending_output, the queue_size
> returned by tiocoutq, or the sum of both?
You should certainly include npending_output. If tiocout
Roland McGrath <[EMAIL PROTECTED]> writes:
> But anyway, I think you can just control DTR directly like other modem
> lines with TIOCM*.
Except that we don't actually support those right now. :)
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Do I use a third thread for assert_dtr? If I need to assert the dtr, the
> only strategy I can think of is to open in blocking mode. However, if I use
> synchronous RPC, this is better done in a seperate thread. I don't know how
> to assert the dt
On Thu, Jan 31, 2002 at 02:11:23PM -0500, Roland McGrath wrote:
> > Do I use a third thread for assert_dtr? If I need to assert the dtr, the
> > only strategy I can think of is to open in blocking mode. However, if I use
> > synchronous RPC, this is better done in a seperate thread. I don't kno
> Well, ok, so I can probably put this into the reader loop, but then I
> finally have to learn about interruptible RPCs, as I will have to interrupt
> a blocking read then. ;)
This is necessary for your plan to work at all. The underlying file will
in fact be open as long as there is a pending
On Thu, Jan 31, 2002 at 02:11:23PM -0500, Roland McGrath wrote:
> > Do I use a third thread for assert_dtr? If I need to assert the dtr, the
> > only strategy I can think of is to open in blocking mode. However, if I use
> > synchronous RPC, this is better done in a seperate thread. I don't kno
> Do I use a third thread for assert_dtr? If I need to assert the dtr, the
> only strategy I can think of is to open in blocking mode. However, if I use
> synchronous RPC, this is better done in a seperate thread. I don't know how
> to assert the dtr otherwise.
You don't need an additional thr
On Wed, Jan 30, 2002 at 02:52:30PM -0800, Thomas Bushnell, BSG wrote:
> I think this is a very good strategy. Mach RPCs can be split into
> asynchronous IPC calls, but this is not true of most RPC systems that
> we might want to port to. So it's ok to take advantage of the Mach
> semantics in Ma
On Thu, Jan 31, 2002 at 01:03:33AM -0800, Thomas Bushnell, BSG wrote:
> A race should always be avoided if it makes a bug. But there may be a
> way to avoid it without select.
Well, the only other idea I have beside io_select would be to have another
look just around the io_write that can be use
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Wed, Jan 30, 2002 at 02:52:30PM -0800, Thomas Bushnell, BSG wrote:
> > The Right Thing is surely two separate threads. I'm not sure that
> > select is really necessary at all however.
>
> I have stumbled upon an obscure race where it helps. I
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The issue I am talking about is implementing pending_output_size correctly,
> which should return the number of bytes pending for output. The problem
> exists only for ioports that have the tiocoutq capability. Because we don't
> know if the underl
On Wed, Jan 30, 2002 at 02:52:30PM -0800, Thomas Bushnell, BSG wrote:
> The Right Thing is surely two separate threads. I'm not sure that
> select is really necessary at all however.
I have stumbled upon an obscure race where it helps. I am not sure if
it is worth the use of io_select, I will
On Thu, Jan 31, 2002 at 03:26:19AM +0100, Marcus Brinkmann wrote:
> It's coming back to me. I wanted to use a select in the writer so I can
> have the actual write non-blocked while holding the global lock. I thought
> this would make the queue manipulation a bit simpler. It's much better
> tho
On Wed, Jan 30, 2002 at 02:52:30PM -0800, Thomas Bushnell, BSG wrote:
> The Right Thing is surely two separate threads. I'm not sure that
> select is really necessary at all however.
It's coming back to me. I wanted to use a select in the writer so I can
have the actual write non-blocked whil
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The obvious difference is what happens to data that is available in the
> underlying file while CREAD is turned off. Both, devio and ptyio discard
> such data, while in your design it would be delayed until CREAD is enabled.
> I couldn't find out wh
Roland McGrath <[EMAIL PROTECTED]> writes:
> I think you should discard data when CREAD is clear. I also think a change
> in CREAD state should be passed down with a tioctl call as for modem
> control bits. When (eventually, with new interfaces) this is passed all
> the way down to the device d
> The obvious difference is what happens to data that is available in the
> underlying file while CREAD is turned off. Both, devio and ptyio discard
> such data, while in your design it would be delayed until CREAD is enabled.
> I couldn't find out what is the right thing (the standards just say
On Wed, Jan 30, 2002 at 02:52:30PM -0800, Thomas Bushnell, BSG wrote:
> I think this is a very good strategy. Mach RPCs can be split into
> asynchronous IPC calls, but this is not true of most RPC systems that
> we might want to port to. So it's ok to take advantage of the Mach
> semantics in Ma
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> An easier question: devio.c uses the _request and _reply functions,
> eg asynchronous I/O, which would work very well in the hurdio case,
> too. However, for hurdio, I think it would work equally well to
> have a reader and a writer thread, which do
Hi,
thanks for your explanations.
An easier question: devio.c uses the _request and _reply
functions, eg asynchronous I/O, which would work very well in the hurdio
case, too. However, for hurdio, I think it would work equally well to have a
reader and a writer thread, which do io_select in a
On Sun, Jan 27, 2002 at 07:39:08PM -0800, Thomas Bushnell, BSG wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > On Tue, Dec 18, 2001 at 01:36:47PM -0800, Thomas Bushnell, BSG wrote:
> > > > error_t (*assert_dtr) (void);
> > >
> > > Turn on DTR.
> > >
> > > > void (*desert_dtr) (v
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> It was my impression that the devio handler tried to detect a blocking write
> and would interpret it as carrier off. So my question is along that line,
> but for the hurdio handler. What I am asking about is the semantics between
> the hurdio node
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Tue, Dec 18, 2001 at 01:36:47PM -0800, Thomas Bushnell, BSG wrote:
> > > error_t (*assert_dtr) (void);
> >
> > Turn on DTR.
> >
> > > void (*desert_dtr) (void);
> >
> > Turn off DTR.
>
> In the hurdio backend, what would be the appropriate
On Tue, Dec 18, 2001 at 01:36:47PM -0800, Thomas Bushnell, BSG wrote:
> > error_t (*assert_dtr) (void);
>
> Turn on DTR.
>
> > void (*desert_dtr) (void);
>
> Turn off DTR.
In the hurdio backend, what would be the appropriate behaviour respective to
blocking? I am a bit confused about that
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> All input parity checking is done by term itself, and the device
> should just do none (or at least provide a way to turn it off).
Oh, things aren't quite right here yet.
First, note that the arg to input_character is a full int. A simple
char
Roland McGrath <[EMAIL PROTECTED]> writes:
> > This is all true. The problem is that Mach's device interface sucks,
>
> What interface would you like for this (parity and break reception)? It
> seems to me that either you need to have a general way to return
> out-of-band exceptional data even
> This is all true. The problem is that Mach's device interface sucks,
What interface would you like for this (parity and break reception)? It
seems to me that either you need to have a general way to return
out-of-band exceptional data events (that are sequenced with regular data),
or else hav
Roland McGrath <[EMAIL PROTECTED]> writes:
> What's questionable to me is some of the funny modes like IGNBRK/BRKINT and
> PARMRK. I guess parity can just be done in term, but it seems desireable
> to pass it down. I think we don't pass it down now in devio because the
> Mach drivers do bogus s
I think Thomas gave you the information you needed, but just to throw a few
things in.
The hurdio bottom half should use the very same term/tioctl interfaces that
term implements for users to diddle the underlying state. It should be
fairly obvious from how term uses the bottom_half functions wh
On Tue, Dec 18, 2001 at 01:44:08PM -0800, Thomas Bushnell, BSG wrote:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > > The pty interface does also not handle START and STOP. It stores
> > > the state in flags, but it does not make use of it in any way.
> >
> > That's a bug.
>
> There
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> > The pty interface does also not handle START and STOP. It stores
> > the state in flags, but it does not make use of it in any way.
>
> That's a bug.
There should be no bug here. Output happens under the control of
pty_io_read, and it does
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> For reference, here is the structure that defines the bottom half.
> For example, there is suspend_physical_output() which supposedly implements
> STOP, and start_output(), which resumes it (but does other things as well).
First, the canonical imple
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The mach terminal device interface is also used for the console device,
> although it of course does not implement any of the status calls. This is
> why STOP (^S) and START (^Q) don't work.
See below for the strategy for the fix.
> The pty interf
Hi,
term has currently two bottom handlers, one for Mach terminal devices, and
one for ptyios. I could make good use of elaborations on some of the
involved issues when going to a user space console.
The mach terminal device interface is also used for the console device,
although it of course d
46 matches
Mail list logo
