Re: [9fans] usb/serial control open

Re: [9fans] usb/serial control open

[lucio]

> The issue is program A can leave things in non-working order
> and program B running after A has to deal with this. This is
> no different from bringing up a system in a known good state.

I think I'd rather be able to have a preceding program be able to set
up the interface and leave it than cater for possible failures and
needing all serial handling programs, irrespective of their
application, needing to go through the set up motions.  I'm with Erik
on this one.

++L

[9fans] usb/serial control open

[erik quanstrom]

it seems odd to me that opening the ctl file would
reset some serial parameters.  wouldn't it be better
to leave them alone?

static int
dopen(Usbfs *fs, Fid *fid, int)
{
	ulong path;
	Serialport *p;

	path = fid->qid.path & ~fs->qid;
	p = fs->aux;
	switch(path){		/* BUG: unneeded? */
	case Qdata:
		dsprint(2, "serial, opened data\n");
		break;
	case Qctl:
		dsprint(2, "serial, opened ctl\n");
		if(p->isjtag)
			return 0;
>>		serialctl(p, "l8 i1");	/* default line parameters */
		break;
	}
	return 0;
}

- erik

Re: [9fans] usb/serial control open

[Gorka Guardiola]

On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> it seems odd to me that opening the ctl file would
> reset some serial parameters.  wouldn't it be better
> to leave them alone?
>

What do you return on read if you don´t know the state?
For some devices if you don´t set the state, you have no idea.
You can do it in read, but it seemed more intuitive in open at the
time, (and you don´t
set the state on every read).


G.

Re: [9fans] usb/serial control open

[erik quanstrom]

On Sun Mar 23 14:35:52 EDT 2014, paurea@gmail.com wrote:
> On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> > it seems odd to me that opening the ctl file would
> > reset some serial parameters.  wouldn't it be better
> > to leave them alone?
> >
> 
> What do you return on read if you don´t know the state?
> For some devices if you don´t set the state, you have no idea.
> You can do it in read, but it seemed more intuitive in open at the
> time, (and you don´t
> set the state on every read).

so if i do this

	echo l7>/dev/eiaU6/eiaUctl
	cat /dev/eiaU6/eiaUctl

that's two opens, isn't it?  then isn't l reset to 8 by the second
open?

- erik

Re: [9fans] usb/serial control open

[Gorka Guardiola]

>
> so if i do this
>
>         echo l7>/dev/eiaU6/eiaUctl
>         cat /dev/eiaU6/eiaUctl
>
> that's two opens, isn't it?  then isn't l reset to 8 by the second
> open?
>

It has been a while and I don´t have the code at hand now, but once
it is at a known state, it shouldn´t set it again, that is probably a bug.

It should be something like:

if(!setonce){
      setonce = 1;
      serialctl(p, "l8 i1");  /* default line parameters */
}

G.

Re: [9fans] usb/serial control open

[Gorka Guardiola]

> What do you return on read if you don´t know the state?
> For some devices if you don´t set the state, you have no idea.
> You can do it in read, but it seemed more intuitive in open at the
> time, (and you don´t
> set the state on every read).
>

What I meant, is if you
write then read, the read does not set the state.
if you read then write, it does.
It is cleaner to set it on open.

The rule is simple, the first open sets the state.
As I said, the "first" part is missing :-).

G.

Re: [9fans] usb/serial control open

[Gorka Guardiola]

On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola <paurea@gmail.com> wrote:

>
> if(!setonce){
>       setonce = 1;
>       serialctl(p, "l8 i1");  /* default line parameters */
> }

And setonce needs to live in the interface, and it needs to be locked, etc.
G.

Re: [9fans] usb/serial control open

[erik quanstrom]

On Sun Mar 23 15:56:52 EDT 2014, paurea@gmail.com wrote:
> On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola <paurea@gmail.com> wrote:
>
> >
> > if(!setonce){
> >       setonce = 1;
> >       serialctl(p, "l8 i1");  /* default line parameters */
> > }
>
> And setonce needs to live in the interface, and it needs to be locked, etc.

another idea: since this is only needed by some hardware.  and then only in init.
why not make it the responsibility of such hardware to do this in the init
fn.  then the problem can be addressed without any special cases like
!setonce.

what do you think?

- erik

Re: [9fans] usb/serial control open

[Gorka Guardiola]

>>
>> And setonce needs to live in the interface, and it needs to be locked, etc.
>
> another idea: since this is only needed by some hardware.  and then only in init.
> why not make it the responsibility of such hardware to do this in the init
> fn.  then the problem can be addressed without any special cases like
> !setonce.
>
> what do you think?
>

Init is probably the right place to do that, except I wouldn't
configure interfaces
I am not going to use, because, some times, they are connected to funky things
(like jtag, for example). I used open to do it on-demand. I don't know
if it was the
right decision, but that was the rationale behind it. If you think
there is a better way, proceed :-).


G.

Re: [9fans] usb/serial control open

[Bakul Shah]

On Sun, 23 Mar 2014 16:32:12 EDT erik quanstrom <quanstro@quanstro.net> wrote:
> On Sun Mar 23 15:56:52 EDT 2014, paurea@gmail.com wrote:
> > On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> >
> > >
> > > if(!setonce){
> > >       setonce = 1;
> > >       serialctl(p, "l8 i1");  /* default line parameters */
> > > }
> >
> > And setonce needs to live in the interface, and it needs to be locked, etc.
>
> another idea: since this is only needed by some hardware.  and then only in i
> nit.
> why not make it the responsibility of such hardware to do this in the init
> fn.  then the problem can be addressed without any special cases like
> !setonce.

On FreeBSD:

     The sio driver also supports an initial-state and a lock-state control
     device for each of the callin and the callout "data" devices.  The
     termios settings of a data device are copied from those of the corre-
     sponding initial-state device on first opens and are not inherited from
     previous opens.  Use stty(1) in the normal way on the initial-state
     devices to program initial termios states suitable for your setup.

A similar idea here would be to have a "default" command to
for default settings. When a device is opened, it is
initialized with these settings. The reason I like this is
because then I don't need to teach every serial IO program
what setting to use (often the other end is a dumb device
requiring its own fixed and peculiar settings).

Re: [9fans] usb/serial control open

[erik quanstrom]

> A similar idea here would be to have a "default" command to
> for default settings. When a device is opened, it is
> initialized with these settings. The reason I like this is
> because then I don't need to teach every serial IO program
> what setting to use (often the other end is a dumb device
> requiring its own fixed and peculiar settings).

i think it is even easier to set the state up properly with cpurc or
consolefs' configuration file, and have the various programs not even
care that they're talking to a serial port.

rdb, for example, was one program that got this wrong.  it was setting
the baud, which backfired in some cases.  not doing anything is a better
solution.  you can always echo bxyz>/dev/eiaXXctl, assuming it really
is a serial line.  :-)

- erik

Re: [9fans] usb/serial control open

[Bakul Shah]

On Sun, 23 Mar 2014 17:53:22 EDT erik quanstrom <quanstro@quanstro.net> wrote:
> > A similar idea here would be to have a "default" command to
> > for default settings. When a device is opened, it is
> > initialized with these settings. The reason I like this is
> > because then I don't need to teach every serial IO program
> > what setting to use (often the other end is a dumb device
> > requiring its own fixed and peculiar settings).
>
> i think it is even easier to set the state up properly with cpurc or
> consolefs' configuration file, and have the various programs not even
> care that they're talking to a serial port.

Not my experience. Occasionally programs do have to care about
some serial port parameters and if such a program crashes you
have a partially working interface. Think CTS/RTS state etc.

Re: [9fans] usb/serial control open

[erik quanstrom]

> > i think it is even easier to set the state up properly with cpurc or
> > consolefs' configuration file, and have the various programs not even
> > care that they're talking to a serial port.
>
> Not my experience. Occasionally programs do have to care about
> some serial port parameters and if such a program crashes you
> have a partially working interface. Think CTS/RTS state etc.

doesn't sound like the common case.  in any event, seems like a
program fiddling with CTS/RTS should do the whole setup, especially
if it plans on crashing.  :-)

- erik

Re: [9fans] usb/serial control open

[Bakul Shah]

On Sun, 23 Mar 2014 20:32:07 EDT erik quanstrom <quanstro@quanstro.net> wrote:
> > > i think it is even easier to set the state up properly with cpurc or
> > > consolefs' configuration file, and have the various programs not even
> > > care that they're talking to a serial port.
> >
> > Not my experience. Occasionally programs do have to care about
> > some serial port parameters and if such a program crashes you
> > have a partially working interface. Think CTS/RTS state etc.
>
> doesn't sound like the common case.  in any event, seems like a
> program fiddling with CTS/RTS should do the whole setup, especially
> if it plans on crashing.  :-)

The issue is program A can leave things in non-working order
and program B running after A has to deal with this. This is
no different from bringing up a system in a known good state.

Re: [9fans] usb/serial control open

[erik quanstrom]

> Init is probably the right place to do that, except I wouldn't
> configure interfaces I am not going to use, because, some times, they
> are connected to funky things (like jtag, for example).  I used open
> to do it on-demand.  I don't know if it was the right decision, but
> that was the rationale behind it.  If you think there is a better way,
> proceed :-).

can you explain a little more about why delaying configuration helps,
and how you are using it, esp with jtag.  for instance, is the usb cable
always connected, even when not in use?

i'm trying to understand here.

- erik