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){
On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom 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
On Sun Mar 23 14:35:52 EDT 2014, pau...@gmail.com wrote:
> On Sun, Mar 23, 2014 at 7:09 PM, erik quanstrom 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´
>
> 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 i
> 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
On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola 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.
On Sun Mar 23 15:56:52 EDT 2014, pau...@gmail.com wrote:
> On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola wrote:
>
> >
> > if(!setonce){
> > setonce = 1;
> > serialctl(p, "l8 i1"); /* default line parameters */
> > }
>
> And setonce needs to live in the interface, and it needs to
>>
>> 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 an
On Sun, 23 Mar 2014 16:32:12 EDT erik quanstrom wrote:
> On Sun Mar 23 15:56:52 EDT 2014, pau...@gmail.com wrote:
> > On Sun, Mar 23, 2014 at 8:47 PM, Gorka Guardiola wrote:
> >
> > >
> > > if(!setonce){
> > > setonce = 1;
> > > serialctl(p, "l8 i1"); /* default line parameters */
>
> 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
On Sun, 23 Mar 2014 17:53:22 EDT erik quanstrom 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 prog
> > 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
On Sun, 23 Mar 2014 20:32:07 EDT erik quanstrom 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
> 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 ration
> 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 cat
15 matches
Mail list logo
