> 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
> 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
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
> > 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 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
> 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 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 */
>
>>
>> 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 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
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.
> 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
>
> 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
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´
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
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){
15 matches
Mail list logo
