Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1241000 > unrolled thread

Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Paul Bolle <pebolle@tiscali.nl> - 2015-10-06 23:10 +0200
    Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Tilman Schmidt <tilman@imap.cc> - 2015-10-12 11:20 +0200
      Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Paul Bolle <pebolle@tiscali.nl> - 2015-10-19 11:10 +0200

#1241000 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

On ma, 2015-09-21 at 18:07 +0200, Tilman Schmidt wrote:
> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
> > ???
> > 
> > The tool you authored will do it from the command line
> > 
> > $ ldattach PPP /dev/ttyS1
> > $ ldattach GIGASET_M101 /dev/ttyS1
> > 
> > Note that nothing here closes the serial device 'in between', and
> > the tty core has switched directly from PPP to GIGASET_M101.
> > n_tty->receive_room is now 64K.
> 
> Indeed it does. I stand corrected. The possibility of running ldattach a
> second time without terminating the first instance didn't occur to me.

Naive question: when would running ldattach a second time make sense?

> > Please add switching from line disciplines other than N_TTY to your
> > regression testing.
> 
> I don't do regression tests for the driver anymore since I stepped down
> as a maintainer, so that would be up to the present maintainer of
> ser_gigaset. But I see no reason for that. As I already explained, N_TTY
> is the only problematic case.

I'm the current maintainer. (By virtue of having a stash of gigaset
hardware _and_ an ISDN capable line _and_ an ISP that still answers when
I do ISDN dial up. That ISP also does ADSL, which I actually use on a
day to day basis.) I try to test whether ISDN still has a pulse, every
RC, but I can't promise much.

(Off topic: does anyone actually _care_ about ISDN? It seems the other
two ISDN maintainers all have effectively left mainline. Now I'm happy
to (lightly!) test mainline ISDN support as long as that's feasible, but
I'd _really_ like to hear from people using ISDN on machines running
currently supported kernels. Are there any left?)

> Again, I won't oppose applying this patch to stable releases before
> 3.10. I just don't see the need, so it would be up to you to advocate
> such a request.

That would be fixing a theoretical problem, as apparently no one managed
to hit this problem before v3.10 _in practice_, so that's not something
I see a need for either.

Thanks,


Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1244512

[Multipart message — attachments visible in raw view] — view raw

Paul,

Am 06.10.2015 um 23:00 schrieb Paul Bolle:
> On ma, 2015-09-21 at 18:07 +0200, Tilman Schmidt wrote:
>> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
>>> ???
>>>
>>> The tool you authored will do it from the command line
>>>
>>> $ ldattach PPP /dev/ttyS1
>>> $ ldattach GIGASET_M101 /dev/ttyS1
>>>
>>> Note that nothing here closes the serial device 'in between', and
>>> the tty core has switched directly from PPP to GIGASET_M101.
>>> n_tty->receive_room is now 64K.
>>
>> Indeed it does. I stand corrected. The possibility of running ldattach a
>> second time without terminating the first instance didn't occur to me.
> 
> Naive question: when would running ldattach a second time make sense?

Peter's argument wasn't about making sense, but about operator error.
While it doesn't make any sense indeed to run two instances of ldattach
in parallel on one and the same serial port, it is entirely conceivable
that someone might do so inadvertently, by not being aware that one is
running already.

Best Regards,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

[toc] | [prev] | [next] | [standalone]

#1250484

[Dropped stable from Cc:. I can't see how this is still relevant for
that list.]

Hi Tilman,

On ma, 2015-10-12 at 11:18 +0200, Tilman Schmidt wrote:
> While it doesn't make any sense indeed to run two instances of
> ldattach
> in parallel on one and the same serial port, it is entirely conceivable
> that someone might do so inadvertently, by not being aware that one is
> running already.

I'm wandering off topic a bit, but doesn't that imply that ldattach
should bail out with an error if someone tries to do that?


Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web